Great explanation and break down Richard. I very much enjoyed this.
-- Tom McGrath III http://lazyriver.on-rev.com 3mcgr...@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@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
