Opacity performance
RobG
well until I tried it on a slow old laptop - the results were awful.
Below is a link to some test pages using FORK, YUI and Scriptaculous to
do a small slideshow and transition effects. Have a play, you'll
notice that peformance differs markedly in different browsers and
platforms:
<URL:
http://members.iinet.net.au/~greenrm/opacitytests/opacitytests.html >
I've decided that any effect should be tested on a slow machine with
integrated graphics before releasing it into the wild. Any effect
should have an end or finish method that is called if the effect is
running too long.
Does anyone have an idea whether setTimeout or setInterval are more
efficient for timed effects?
Peter Michaux
On 1/6/07, RobG <rg...@iinet.net.au> wrote:
>
> I decided to create a bit of a slideshow and thought I was doing really
> well until I tried it on a slow old laptop - the results were awful.
Gulp!
> Below is a link to some test pages using FORK, YUI and Scriptaculous to
> do a small slideshow and transition effects. Have a play, you'll
> notice that peformance differs markedly in different browsers and
> platforms:
>
> <URL: http://members.iinet.net.au/~greenrm/opacitytests/opacitytests.html >
I think that some of the conclusions might need to be reconsidered
and maybe some of the tests changed for apples-to-apples comparisons.
The tests are for the efficiency of the opacity setting *and* effects
library from YUI, Scriptaculous and Fork. However Fork doesn't have an
effects library and you filled that gap which is a worthwhile
experiment but these conclusions don't really apply to Fork
completely. If you are interested in testing opacity I think it would
be good to use the same animation code in the three cases. If you are
interested in testing animation I think it would be good to use the
same opacity setting code.
Looking in the effects.js file you wrote to use with the Fork test it
looks like with each animation step you read the current opacity. This
will add time to the effect. I imagine the YUI animation library
caches the last value and then just increments and sets it during the
next step of the animation. I'm not sure but that is how I have
animated things in the past.
The Opacity setting code for Fork is so similar to YUI I am inclined
to think that the animation code is the difference. I can see a couple
ways to speed up the opacity setting code in Fork that are relatively
easy to do but I did think before that the changes would make little
difference.
I'm installing Windows now on a 450 MHz computer and will make some
tests and comparisons also.
Peter
Peter Michaux
> >
> > I decided to create a bit of a slideshow and thought I was doing really
> > well until I tried it on a slow old laptop - the results were awful.
= PROCEDURE =
I made two test pages.
<URL: http://peter.michaux.ca/temp/OpacityAnimation/show_fork.html>
<URL: http://peter.michaux.ca/temp/OpacityAnimation/show_ie.html>
The first test, TEST FORK, is written using Fork's setOpacity()
function and the other, TEST IE, is custom code written to work in IE.
The only difference between the two is that the version for IE
directly sets the filter properties of the two images being cycled in
the animation. So these tests can be compared to see if it is the Fork
setOpacity() function that is responsible for jerky animations on an
old computer running Win/IE.
Each test lasts for 4000 ms and each setTimeout is set for 40 ms. So
if the actually redraw of each frame was zero time then there would be
101 frames in the animation. This would be true for either the TEST
FORK or TEST IE.
I ran both tests on my 450 MHz Dell. This computer 256 MB RAM and has
an ATI 3D Rage Pro AGP 2x (GT-C2U2) card graphics card with 8MB
memory. The computer is running Windows XP and IE 6.
= RESULTS =
Both tests were very jerky between frames indicating my computer is
old enough to use for these tests.
When the tests are finished the web page reports how many frames the
animation was able to squeeze into the 4000 ms. Both tests reported
either 25 or 26 frames.
Watching the Windows Task Manager Performance tab both tests had very
similar CPU usage spikes in the CPU Usage History graph. The CPU usage
was up to 100% for the majority of the animation.
For comparision, I ran TEST FORK on my MacBook Pro in Firefox 2 and it
reported 75-78 frames which was visibly very smooth.
= CONCLUSION =
I did not detect *any* difference in animation performance between
using the Fork.setOpacity() function and fast custom code to
manipulate the opacity in IE on an old, slow computer.
Peter
--
Fork JavaScript: http://forkjavascript.org
RobG
> > Below is a link to some test pages using FORK, YUI and Scriptaculous to
> > do a small slideshow and transition effects. Have a play, you'll
> > notice that peformance differs markedly in different browsers and
> > platforms:
> >
> > <URL: http://members.iinet.net.au/~greenrm/opacitytests/opacitytests.html >
>
> I think that some of the conclusions might need to be reconsidered
> and maybe some of the tests changed for apples-to-apples comparisons.
> The tests are for the efficiency of the opacity setting *and* effects
> library from YUI, Scriptaculous and Fork. However Fork doesn't have an
> effects library and you filled that gap which is a worthwhile
> experiment but these conclusions don't really apply to Fork
> completely. If you are interested in testing opacity I think it would
> be good to use the same animation code in the three cases. If you are
> interested in testing animation I think it would be good to use the
> same opacity setting code.
Good suggestion, I was doing this as a bit of fun so didn't really do a
proper testing job (hence the subjective results).
>
> Looking in the effects.js file you wrote to use with the Fork test it
> looks like with each animation step you read the current opacity. This
> will add time to the effect. I imagine the YUI animation library
> caches the last value and then just increments and sets it during the
> next step of the animation. I'm not sure but that is how I have
> animated things in the past.
I was trying to keep the code more concise by not storing yet another
variable within the transition object, however clearly that would be
better. I was also trying to work out the best way if two transitions
run into each other - if an image is fading and is told to appear, what
should it do?
I hadn't quite finished that thought, but now I think I know what needs
to be done.
--
Rob
RobG
[...]
> I made two test pages.
>
> <URL: http://peter.michaux.ca/temp/OpacityAnimation/show_fork.html>
>
> <URL: http://peter.michaux.ca/temp/OpacityAnimation/show_ie.html>
> Each test lasts for 4000 ms and each setTimeout is set for 40 ms. So
> if the actually redraw of each frame was zero time then there would be
> 101 frames in the animation. This would be true for either the TEST
> FORK or TEST IE.
>
> I ran both tests on my 450 MHz Dell. This computer 256 MB RAM and has
> an ATI 3D Rage Pro AGP 2x (GT-C2U2) card graphics card with 8MB
> memory. The computer is running Windows XP and IE 6.
>
> = RESULTS =
>
> Both tests were very jerky between frames indicating my computer is
> old enough to use for these tests.
>
> When the tests are finished the web page reports how many frames the
> animation was able to squeeze into the 4000 ms. Both tests reported
> either 25 or 26 frames.
I think this proves my theory about the graphics card - my S3 laptop
only gets 11 frames in Firefox and 7 in Opera - and you thought 26 was
jerky! IE reported 19 frames for the IE-specific test and 18 for the
FORK-based test.
>
> Watching the Windows Task Manager Performance tab both tests had very
> similar CPU usage spikes in the CPU Usage History graph. The CPU usage
> was up to 100% for the majority of the animation.
>
> For comparision, I ran TEST FORK on my MacBook Pro in Firefox 2 and it
> reported 75-78 frames which was visibly very smooth.
That's terrific, you just convinced me to get a MacBook Pro rather than
the cheaper non-Pro - the CPU is fantastic but integrated graphics
suck.
I ran your test in a Core Duo/PCIe iMac and go 82 frames in Safari, 62
in Firefox. A G4/AGP iMac got 50 for Safari and 32 for Firefox and a
commendable 53 in Opera.
Have a read of this (totally unrelated) thread at RoRspinoffs for some
amazing Mac performance scores - I presume they were run on a quad
processor Mac Pro:
<URL:
http://groups.google.com.au/group/rubyonrails-spinoffs/browse_frm/thread/d63bd16dc80eae91/?hl=en#
>
> = CONCLUSION =
>
> I did not detect *any* difference in animation performance between
> using the Fork.setOpacity() function and fast custom code to
> manipulate the opacity in IE on an old, slow computer.
The real differences are browsers (Firefox seems slowest) and graphics
capabilities.
Clearly I need to implement some performance enhancements in my fade
effect, notably store values rather than look them up and finish
effects that are running too slow. I'd also like to test running
effects using setInterval rather than setTimeout - Scriptaculous (which
uses setInterval) shows spikey CPU usage rather than the flat 100% of
setTimeout based code.
--
Rob
RobG
RobG wrote:
[...]
> The real differences are browsers (Firefox seems slowest) and graphics
> capabilities.
I just ran the FORK test on a 2.6 GHz P4 with XP and integrated
graphics and got 30 frames in Firefox and 86 in IE. The IE test shows
86 frames in IE.
--
Rob
Peter Michaux
Holy Cow!
Any idea why Firefox's rendering is so slow or how IE is capable of
squeezing out so much speed from the same hardware?
RobG
Peter Michaux wrote:
> On 1/7/07, RobG <rg...@iinet.net.au> wrote:
> >
> > RobG wrote:
> > [...]
> > > The real differences are browsers (Firefox seems slowest) and graphics
> > > capabilities.
> >
> > I just ran the FORK test on a 2.6 GHz P4 with XP and integrated
> > graphics and got 30 frames in Firefox and 86 in IE. The IE test shows
> > 86 frames in IE.
>
> Holy Cow!
>
> Any idea why Firefox's rendering is so slow or how IE is capable of
> squeezing out so much speed from the same hardware?
I can only guess that IE is more adept at using integrated graphics -
after all, the CPU has stacks of grunt, it's the graphics component
that is crippled. I'll bet if you try the FORK version with Safari on
your MacBook Pro (Core2Duo?) rather than Firefox, you'll get similar
numbers.
This may shed some light:
<URL:
http://weblogs.mozillazine.org/tor/archives/2006/04/why_cairo.html >
--
Rob
Peter Michaux
> I'll bet if you try the FORK version with Safari on
> your MacBook Pro (Core2Duo?) rather than Firefox, you'll get similar
> numbers.
I get 77 with Firefox and 83 with Safari.
> This may shed some light:
>
> <URL:
> http://weblogs.mozillazine.org/tor/archives/2006/04/why_cairo.html >
Interesting. Firefox 3 really isn't that far into the future. I'm
looking forward to seeing what what happens as 3 is supposed to focus
on new rendering techniques/engine.
segdeha
> On 1/6/07, RobG <r...@iinet.net.au> wrote:
>
> > I decided to create a bit of a slideshow and thought I was doing really
> > well until I tried it on a slow old laptop - the results were awful.
Hi, first time posting. Haven't actually even used Fork yet (though I'm
excited about it!).
I have written fading slideshow scripts before and ended up borrowing
some techniques from code provided for Apple's Dashboard widgets.
Basically, the way they write it, the fading effect is on a timer and
if the time runs out before the opacity gets there, it just skips to
the end point.
This doesn't make for smooth fading on slow machines, but at least it's
reliable in the sense that it doesn't hang.
You can see my big, clunky fading slideshow code on my homepage:
http://andrew.hedges.name/
I have also implemented this a little more cleanly in my SlideShow
Dashboard widget: http://andrew.hedges.name/widgets/#slideshow
Also, it might be worth a look at the Apple Classes for widget
developers, specifically the animation class.
FWIW,
-Andrew
RobG
segdeha wrote:
> On Jan 6, 10:16 am, "Peter Michaux" <petermich...@gmail.com> wrote:
> > On 1/6/07, RobG <r...@iinet.net.au> wrote:
> >
> > > I decided to create a bit of a slideshow and thought I was doing really
> > > well until I tried it on a slow old laptop - the results were awful.
>
> Hi, first time posting. Haven't actually even used Fork yet (though I'm
> excited about it!).
>
> I have written fading slideshow scripts before and ended up borrowing
> some techniques from code provided for Apple's Dashboard widgets.
> Basically, the way they write it, the fading effect is on a timer and
> if the time runs out before the opacity gets there, it just skips to
> the end point.
Yes, I worked out that is the best way to do it. I should have noted
in my original post that the performance wasn't FORK's problem, it is a
general problem with using opacity on machines with poor graphics
performance. Peter's opacity performance page is a nice tool for
testing.
>
> This doesn't make for smooth fading on slow machines, but at least it's
> reliable in the sense that it doesn't hang.
>
> You can see my big, clunky fading slideshow code on my homepage:
> http://andrew.hedges.name/
I'll try that in some of my old test machines and let you know...
>
> I have also implemented this a little more cleanly in my SlideShow
> Dashboard widget: http://andrew.hedges.name/widgets/#slideshow
And that...
>
> Also, it might be worth a look at the Apple Classes for widget
> developers, specifically the animation class.
And that... cheers.
--
Rob
Peter Michaux
>
> On Jan 6, 10:16 am, "Peter Michaux" <petermich...@gmail.com> wrote:
> > On 1/6/07, RobG <r...@iinet.net.au> wrote:
> >
> > > I decided to create a bit of a slideshow and thought I was doing really
> > > well until I tried it on a slow old laptop - the results were awful.
>
> Hi, first time posting. Haven't actually even used Fork yet (though I'm
> excited about it!).
Welcome.
> I have written fading slideshow scripts before and ended up borrowing
> some techniques from code provided for Apple's Dashboard widgets.
> Basically, the way they write it, the fading effect is on a timer and
> if the time runs out before the opacity gets there, it just skips to
> the end point.
Suppose you want opacity to go from 1 to 5 (arbitrary units) in 1
second. The movie would look like this if each redraw takes no time
and we set a pause of 0.25 s between redraws
0.00 s: 1
0.25 s: 2
0.50 s: 3
0.75 s: 4
1.00 s: 5
But if each redraw takes 0.1 s and the pause between redraws is still
0.25 s then it would be
0.00 s: 1
0.35 s: 2
0.70 s: 3
1.05 s: 4
1.40 s: 5
And what I think you are saying is that is too long. So when the time
reaches 1s just call it quits and jump straight to 5. Which would look
like this
0.00 s: 1
0.35 s: 2
0.70 s: 3
1.00 s: 5
That is a big jump from 3 directly to 5 at the end.
The way I wrote the test earlier in this thread used a linear equation
to determine the new opacity whenever the code finally got around to
each redraw. Still with a 0.25 s pause and 0.1 s redraw I would have
this
0.00 s: 1
0.35 s: 2.4
0.70 s: 3.8
1.00 s: 5
Although I didn't fuss about hitting the 1.00 s mark exactly. Just
finish on the first frame after 1 s.
This distributes the jumpiness over the multiple redraws instead of
saving them up for one huge jump at the end. This would be very
dramatic if there was the intention of 100 redraws in 1 s and the
slow computer with a 0.1 s redraw time only managed 10 redraws leaving
the last jump to be really huge like this
1
1.04
1.08
1.12
1.16
1.20
1.24
1.28
1.32
1.36
5
I think equations are the way to go and lead to smoother experience
overall then a catch-up at the last frame.
seg...@gmail.com
> I think equations are the way to go and lead to smoother experience
> overall then a catch-up at the last frame.
Peter,
Yours and Rob's replies were admirable in their patience. :^) I
realized soon after I sent my note that you had thought this through
better than I suspected on first glance. I agree that it makes the
most sense to compute the closest opacity on each iteration.
Cheers,
-Andrew