On Thu, 04 Dec 2008 07:12:30 +0100, Frank Bruder <[EMAIL PROTECTED]> wrote:

> Great work so far. Just three comments:
...
> - Your testing method does not necessarily measure a relevant
> benchmark. A scripting engine which queues events in such a way that
> interval and timeout events always are executed in the correct order
> would get perfect scores, no matter how much time the rendering takes.
> In the second call to setInterval() you could create a Date object
> each time and use that for measuring, to account for the possibility
> that the longer interval might be delayed in accordance with the
> shorter interval. Furthermore a user agent could switch to rendering
> only every other frame when the animation speed would otherwise slow
> down too much. Video player software commonly does this.

I would agree that doing DOM modifications and checking how long it took before 
it could do the next update/modification isn't necessarily very accurate. If 
little or no rendering is done at all, then you'd probably get a very high 
score.

There's no guarantee that the DOM modifications actually result in a new 
rendering before the next update call. This is what Frank is getting at about 
dropping frames, there's no guaranteed framerate.

Second, the Date objects / timers that are used can have varying 
resolution/quality in browsers, and across platforms. That may skew results.

Third, in any case why would you need a framerate higher than the screen 
refreshrate? For the DOM modifications sure, they should be expected to run as 
fast as possible. But unless you run with vertical sync disabled you'll not see 
the frames that are produced in excess of the screen's refreshrate, and if you 
do get the extra frames then you may well see tearing problems. So yes, it's 
good if the DOM modifications are as fast as possible, and yes it's good if the 
viewer can produce frames faster than it needs to actually draw them on screen, 
but I don't think that you're measuring actual rendering framerates. Another 
justified question would be: if you're not going to see the frames anyway, why 
should valuable CPU time be wasted rendering them?

Anyway, you may want to check out the SVGSVGElement.currentFps[1] DOM API in 
the just released[2] Opera 10 for comparison. That property will provide the 
average framerate based on samples from when the svg was actually rendered to 
screen.

And I want to add that performance testing is really important, and that the 
above points in no way invalidate your work. They're just things that may skew 
the results. What you see on your screen and in CPU and memory usage is what 
really counts IMHO, and it's clear that in that respect the SVG viewers keep 
improving at a steady rate.

Cheers
/Erik

[1] http://dev.opera.com/articles/view/presto-2-2-and-opera-10-a-first-look/
[2] http://www.opera.com/browser/next/

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

------------------------------------

-----
To unsubscribe send a message to: [EMAIL PROTECTED]
-or-
visit http://groups.yahoo.com/group/svg-developers and click "edit my 
membership"
----Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/svg-developers/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/svg-developers/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[EMAIL PROTECTED] 
    mailto:[EMAIL PROTECTED]

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply via email to