Another examples of the screen refresh problem on the Mac?

[Richard Gaskin]

James Hurley wrote:

> Thank you for this Bernd. It is going to take me a while to digest these new graphic features in 5.0. I confess I am unaware of the interaction between RR code and the display on the screen. That's probably important. :-)
>
> Like you, I don't see much improvement of 5.0 over 4.6 in animation.  The effect of lowering the syncRate, not so much the rate as the time between syncs (?), is significant, but then that was something available to us in 4.6--except that I didn't know it. The nomenclature suggests that it is the frequency, when it appears to be the period. And, as we all learned in physics, one is the reciprocal of the other.
>
> I would like to see a little help from RR on these new features--by way of a demonstration stack perhaps.

Yes, I think that's going to be necessary, and over time as more is 
understood about the new rendering scheme, hopefully there will also be 
more intelligent defaults so users can immediately see at least some 
benefit without having to do multiple iterations of experimentation.

The v5.0 rendering engine represents perhaps the biggest change in the 
history of the engine to how objects are rendered on screen.   The 
upside is that it's possible to see graphics performance increase many 
times over previous versions.  The downside is that it's not easy to 
realize that performance gain without a great deal of experimentation.

In earlier versions, cards were rendered using a very brute-force 
method, in which every time there was a screen refresh every object was 
rendered from back to front until all had been rendered, and then that 
composite image was copied to the graphport of the window in which the 
card is displayed.

So simply moving a single billiard ball, which might actually affect 
only one small portion of the screen, caused the entire screen to go 
through that rendering process.  It was thorough and robust, but often 
redundant.

In the new rendering engine, the screen composite is divided into tiles, 
and logic is applied to determining whether a given tile is affected by 
a given change.  Those tiles that are affected will be re-rendered, 
while those that aren't will simply retain their last rendering and use 
that to copy to the window for the finished result.

There is a certain amount of additional internal overhead to this tiled 
scheme, however, since it now has to keep track of multiple sections of 
the screen and run through that hit-testing to determine which ones need 
to be re-rendered.  On the one hand, more tiles can mean less 
re-rerendering, but on the other hand it means more tile management.

So the key to using the new graphics engine effectively boils down to 
finding the right tile size optimal for your particular layout and the 
nature of the changes happening within it.

If you have relatively small objects whose changes affect relatively 
small portions of the screen, you may find a smaller tile size will 
offer greater performance.

But if even a small object moves over a large area, a larger tile size 
may provide even better performance.

The optimal tile size can't be known in advance, because it depends on a 
wide variety of factors driven by scripts that may exist in the objects 
on the card themselves, or even in some remote library, and the sum of 
their interactions may be too complex to expect that the engine can 
figure out in advance how to set an optimal tile size.

So in v5, to take advantage of this new rendering scheme we need to 
experiment with different tile sizes, some larger and some smaller, and 
perhaps even different rendering engines on the platforms they're 
available on (LC now uses OpenGL, for example, on platforms where that 
technology is available).

Through the evolution of this new engine, developers on the dev list 
noted a wide range of performance results from "worse than before" to 
"OMG this thing just flies!", depending on the different combinations of 
tile sizes and other rendering options they took the time to experiment 
with.

Given the complexity of the new renderer, and how much conceptualization 
and experimentation is required by the user to use it well, it could be 
argued that it has introduced a level of complexity that seems 
counter-productive to RunRev's goal of delivering the simplest system 
possible for delivering professional software.

But I believe that as we use it more often, and as experimentation and 
development continue at RunRev, we will shortly see ever-better versions 
of this engine which are able to apply defaults which provide at least 
some of the benefits, leaving further performance enhancement to those 
developers who need it and will be willing to put in the time to apply 
it effectively.

In the meantime, it's my understanding that the current defaults should 
be using rendering methods roughly on par with previous versions, so 
ideally just running stuff you've already written should perform as well 
as it did before.

And if you want it even faster, just set aside some time to experiment 
with different tile sizes and chances are you'll have a "Wow!" moment 
once you find the right combination for your layout.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv