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
