Another examples of the screen refresh problem on the Mac?

[Thomas McGrath III]

Great explanation and break down Richard. I very much enjoyed this.


-- Tom McGrath III
http://lazyriver.on-rev.com
3mcgrath at comcast.net

On Oct 12, 2011, at 9:54 AM, Richard Gaskin wrote:

> 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
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode