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/
