On Thu, 04 Dec 2008 15:28:40 +0100
Erik Dahlström <[EMAIL PROTECTED]> wrote:
> 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.
We would hope that we could get updates faster than the rendering. But
if you don't then it is a result I would like to be able to measure. I
had actually planned to go into more detail on this, but the article
was getting so long that I was afraid mo one would be willing to read
it.
> Second, the Date objects / timers that are used can have varying
> resolution/quality in browsers, and across platforms. That may skew
> results.
I really need to put some tie into a sidebar on potential points of
error in the measures. I mentioned a few, but they aren't coherent
enough to show the biases I was aware of. Without that section, I
really don't have a good place to add notes like these.
I remember that the Javascript Date object in most browsers used to be
lousy a decade ago. I should have mentioned that.
> 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?
I, personally, only want a refresh rate fast enough to generate smooth
animation. My goal was less to brag on a particular potential update
rate than to explore some of the edges of what's possible. After
reading a few of the emails here I don't seem to be clear enough on my
intended goal.
> 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.
Sounds really useful. I'll try to check it out when I dig out from
under my current project.<grin/>
> 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.
I do want to thank you for your insights and comments. This project
started as a quick test to see if a few of my pages were "fast enough",
but I've kind of moved in the direction of trying to put numbers to the
idea that SVG is "fast enough".
I'm not really qualified to make that determination, but with the input
I've gotten so far on this list, I hope to make something we can point
to we people say that SVG would be too slow for animation or
instrumentation or games or whatever.
Thank you again for taking the time to comment. I'll incorporate your
ideas where I can in the next revision.
G. Wade
--
Results are what you wanted, consequences are what you got.
-- Michael VanDusen
------------------------------------
-----
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/
