Re: Another examples of the screen refresh problem on the Mac?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Another examples of the screen refresh problem on the Mac?

jim hurley
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.

Jim Hurley



>
> Message: 10
> Date: Tue, 11 Oct 2011 12:40:46 -0700 (PDT)
> From: BNig <[hidden email]>
> To: [hidden email]
> Subject: Re: Another examples of the screen refresh problem on the
> Mac?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> to anyone who is interested in the stack moving two graphics and different
> settings of syncrate, a handler that calls itself and does a lock screen
> wait for syncrate milliseconds and unlock screen
> and the Livecode 5.0 options of compositortype/tile/cache and layer mode and
> wants to test all the possible variations by optionMenus checkboxes etc here
> is the stack to test (basically the one I sent to Jim Hurley plus the
> livecode 5 options)
>
> berndniggemann.on-rev.com/movegraphic/movegraphic.livecode.zip
>
> I still don't seem to get the Livecode 5.0 graphic options. At least I only
> see minor improvements with moving two graphics along a path of 180 points.
>
> The largest effect on smoothness comes from reducing the syncrate. And I
> agree with Colin that the dictionary has it the wrong way around: the lower
> the syncrate the smoother the movement and the higher the processor load.
>
> A little to the smoothness is added by calling a handler during movement
> that lock/pauses/unlocks the screen. Graphic effects do not seem to be of
> much difference.
>
> I am still not shure about the optimal settings.
>
> Kind regards
>
> Bernd


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: 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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Another examples of the screen refresh problem on the Mac?

BNig
Hi Richard,

thank you for outlining the architecture of the new 5.0 LiveCode graphics engine. That shurely helps to take advantage of it. And as you pointed out we will have to experiment to find a setting that suits a particular situation.
It just happens that Jim brought up the problem of moving simultaneously two graphics along the points of a graphic. And that he was not pleased with it. If you like you can test that scenario:

http://berndniggemann.on-rev.com/movegraphic/movegraphic.livecode.zip

From all the many variations I did for this particular task, it seems that simply setting the syncrate from 20 to e.g. 16 improves the smoothness of the movement tremendously. That applies to 4.6 as well as 5.0

The new graphics engine features do improve movement but again with the new graphic features setting the syncrate to 16 improves movement considerably. In this particular instance more than the new features at a syncrate of 20.

Do you or anybody else have some more information on syncrate?

Kind regards

Bernd

Reply | Threaded
Open this post in threaded view
|

Re: Another examples of the screen refresh problem on the Mac?

J. Landman Gay
In reply to this post by jim hurley
On 10/12/11 8:10 AM, James Hurley wrote:

> I would like to see a little help from RR on these new features--by
> way of a demonstration stack perhaps.

We all would. Richard's explanation was very good and with a few
guidelines I think we'll all catch on eventually and jaws will drop. I
know that in my sample stack, it went from barely useable on mobile
platforms to amazingly smooth -- at least, on my particular tablet. I
gave it to Richard to test and it failed miserably. I'm sure it has
something to do with tile size and cache limits but I need some info on
how to calculate those. Right now I'm stabbing in the dark.

As I understand it, the cache isn't so important on desktop builds or in
stacks. Computers have plenty of RAM these days so set it as high as you
want for now. Tile size probably matters though.

What I'd suggest for now is to play with the new settings in 5.0 and see
what you come up with. It took me about a day to get something to work,
but once it did I was awfully impressed.

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Another examples of the screen refresh problem on the Mac?

jim hurley
In reply to this post by jim hurley
These are exciting times for RR.

I am grateful to all who have responded to this thread--Bernd, Bob, Kevin, Jacque, Ken, et. al.

And special thanks to Richard for taking the time for his expansive discussion of the new features. THANK YOU.

I am grateful, but..... I am not satisfied. I would like to see one example, one animation stack from RR, that is manifestly improved in 5.0 over 4.6

I will do my part. I have put together a stack/library of graphic routines together will multiple examples of their use in the following stack:

   go url "http://jamesphurley.com/jhurleyFolder/ProgrammableGraphics.livecode"

It should run in both 4.0 and 5.0  Here are dozens of animations on which to test 5.0. New commands and functions for graphically programming lines (setAngle, getAngle, setLength, getLength, JoinLines. Plus intersection points of overlapping circles, tangent lives to ellipses, collision detection inside a convex polygon, etc.

After 40 years of teaching I have come to one immutable conclusion: People learn best and most easily by example. (That's why Winkler and Kamins was such a great book from which to learn HyperTalk.) An example is worth a thousand pictures, and you know how many words a picture is worth. (Good grief, that compounds to a million words.) So I would like to see one example from RR to celebrate the animation capabilities of 5.0

But once again, I am grateful for RR's continued efforts to improve animation. I realize that is not a high priority at this time of such emphasis on mobil applications.

Jim Hurley



>
> Message: 25
> Date: Wed, 12 Oct 2011 06:54:51 -0700
> From: Richard Gaskin <[hidden email]>
> To: [hidden email]
> Subject: Re: Another examples of the screen refresh problem on the
> Mac?
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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.

(skip)

> 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
> [hidden email]
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> End of use-livecode Digest, Vol 97, Issue 26
> ********************************************


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Another examples of the screen refresh problem on the Mac?

Thomas McGrath III-3
In reply to this post by Richard Gaskin
Great explanation and break down Richard. I very much enjoyed this.


-- Tom McGrath III
http://lazyriver.on-rev.com
[hidden email]

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


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode