Loading ...
Sorry, an error occurred while loading the content.

Re: [svg-developers] Report on SVG Viewer Performance

Expand Messages
  • G. Wade Johnson
    On Mon, 1 Dec 2008 10:38:26 +1100 ... ... I ll see what I can do. ... This has turned into a bigger project than I originally intended. But with the
    Message 1 of 18 , Nov 30, 2008
    • 0 Attachment
      On Mon, 1 Dec 2008 10:38:26 +1100
      Cameron McCormack <cam@...> wrote:

      > G. Wade Johnson:
      > > Right. I tried to explain that as the reason for the cut off.
      > > (Obviously, I need to work on my explanation a bit.)
      >
      > I see now that you did. I think the problem was more one of me firing
      > off the email before reading in detail. :)

      <grin/>

      > > One of the things for later testing would be to perform multiple
      > > 'updates' in each interval to try for higher quality results. I get
      > > a small measure of that by the variability introduced by the three
      > > different tests.
      > >
      > > So, I obviously need to add clarity in my explanation of what I'm
      > > expecting to get from this test.
      >
      > Something that explains how the results from that minimal test affect
      > how you run/interpret subsequent tests would be good.

      I'll see what I can do.

      > [From the document:]
      > > There have been a number of reports that some viewers (notably
      > > Batik) are slow with some text operations.
      >
      > I’d be interested to see the results of those future tests. I haven’t
      > done any profiling to see exactly what about text updates are slow.

      This has turned into a bigger project than I originally intended. But
      with the tools I've built (and begun to describe) I should be able to
      do more basic profiling of some features to see what effects people can
      expect.

      I plan to post everything I find and try to keep the community
      up-to-date. I would really like to have hard numbers to point to when
      talking about performance.

      Thanks again for your input.
      G. Wade
      --
      A product's only late once, but it can suck forever.
      -- Ben Spees, Ambrosia Software
    • Helder Magalhães
      ... Yeah, I recall John Resig recently blogging about Web browser timing [1]. Although IE is pointed as the one suffering more from timing issues, and the
      Message 2 of 18 , Dec 2, 2008
      • 0 Attachment
        > One thing that stands out to me on first glance: desktop web browsers
        > impose a lower limit on timer callbacks with setTimeout() and
        > setInterval(), for web compatibility reasons.

        Yeah, I recall John Resig recently blogging about Web browser timing
        [1]. Although IE is pointed as the one suffering more from timing
        issues, and the study doesn't include it, if you intend to update your
        research with IE+plug-in (ASV, Renesis or similar) or if someone
        attempts to do it, it may a good idea to leave a footnote or similar
        so this is kept in mind. ;-)

        Cheers,

        Helder Magalhães

        [1] http://ejohn.org/blog/accuracy-of-javascript-time/
      • G. Wade Johnson
        On Tue, 02 Dec 2008 10:10:40 -0000 ... At the moment, I m running pure Linux, so IE is not a testable option. I probably need to get a VM up to test IE. ... I
        Message 3 of 18 , Dec 2, 2008
        • 0 Attachment
          On Tue, 02 Dec 2008 10:10:40 -0000
          Helder Magalhães <helder.magalhaes@...> wrote:

          > > One thing that stands out to me on first glance: desktop web
          > > browsers impose a lower limit on timer callbacks with setTimeout()
          > > and setInterval(), for web compatibility reasons.
          >
          > Yeah, I recall John Resig recently blogging about Web browser timing
          > [1]. Although IE is pointed as the one suffering more from timing
          > issues, and the study doesn't include it, if you intend to update your

          At the moment, I'm running pure Linux, so IE is not a testable option.
          I probably need to get a VM up to test IE.

          > research with IE+plug-in (ASV, Renesis or similar) or if someone
          > attempts to do it, it may a good idea to leave a footnote or similar
          > so this is kept in mind. ;-)

          I can update the section about the lower limits on Firefox and Opera. I
          probably also need a section on the limitations and possible error
          modes of this profiling approach.

          > [1] http://ejohn.org/blog/accuracy-of-javascript-time/

          That looks like a good article.

          Thanks for the input.
          G. Wade
          --
          Contrary to popular opinion, the plural of 'anecdote' is not 'fact'.
        • Helder Magalhães
          ... Probably more modifications are required: for example, ASV and Renesis don t accept a method as setInterval/setTimeout argument - a string must be used
          Message 4 of 18 , Dec 3, 2008
          • 0 Attachment
            > At the moment, I'm running pure Linux, so IE is not a testable
            > option. I probably need to get a VM up to test IE.

            Probably more modifications are required: for example, ASV and Renesis
            don't accept a method as setInterval/setTimeout argument - a string
            must be used instead... :-|


            > Thanks for the input.

            You're welcome. ;-)


            I've read through the article - which I found quite valuable, by the
            way - and have a few comments which I'd like to share.

            1. There are some limitations while using "setInterval":
            1.1. As far as I know, setInterval doesn't consider the time it
            takes to execute the code block called. This means that if you have a
            very short interval and a heavy (long/heavy) block of code, you may
            not get the desired behavior (read as: things can go pretty messy).
            Although scripting is executed as single thread, which assures that no
            nasty interactions will occur, nevertheless the timing may messed up.
            Please correct me if I'm wrong!
            1.2. Firefox as a known issue [1] with this particular timing
            mechanism. While it's pretty harder to reproduce using Firefox 3 than
            in Firefox 2, it still applies...
            1.3. I'd generally propose "setTimeout" as a timing mechanism
            (called each time, immediately before returning), specially when the
            time consumed in the called method isn't relevant (and, even so, one
            can simply measure the time it took).

            2. Couple of suggestions:
            2.1. In "What I'm Trying to Measure", maybe referencing (link to?)
            the Firefox bug around the "setInterval" text wouldn't be a bad idea,
            at least to point out this known limitation;
            2.2. In "Measurement Methodology", I also believe mentioning
            (linking to?) the Batik bug report for the programmatic navigation
            feature [4] would also be valuable - one can then see when and how was
            it fixed (thanks for contributing it, as we're at it).

            3. Few typos which I think you will appreciate:
            3.1. In "Rationale" [5], "surpised" --> "surprised";
            3.2. In "The Instruments Test" [6], "modification to" -->
            "modification of" (?);
            3.3. In "The Wuse Test" [7], "hghest" --> "highest";


            Cheers,

            Helder Magalhães


            [1] https://bugzilla.mozilla.org/show_bug.cgi?id=291386
            [2] http://anomaly.org/wade/projects/svg/profiling/#what_measure
            [3] http://anomaly.org/wade/projects/svg/profiling/#methodology
            [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=46072
            [5] http://anomaly.org/wade/projects/svg/profiling/#rationale
            [6]
            http://anomaly.org/wade/projects/svg/profiling/#instruments_test_results
            [7] http://anomaly.org/wade/projects/svg/profiling/#wuse_test_results
          • G. Wade Johnson
            On Wed, 03 Dec 2008 12:04:06 -0000 ... I vaguely remember that from back in the old days. Thanks for reminding me. ... I believe this is the reason for the
            Message 5 of 18 , Dec 3, 2008
            • 0 Attachment
              On Wed, 03 Dec 2008 12:04:06 -0000
              Helder Magalhães <helder.magalhaes@...> wrote:

              > > At the moment, I'm running pure Linux, so IE is not a testable
              > > option. I probably need to get a VM up to test IE.
              >
              > Probably more modifications are required: for example, ASV and Renesis
              > don't accept a method as setInterval/setTimeout argument - a string
              > must be used instead... :-|

              I vaguely remember that from back in the old days. Thanks for reminding
              me.

              > > Thanks for the input.
              >
              > You're welcome. ;-)
              >
              >
              > I've read through the article - which I found quite valuable, by the
              > way - and have a few comments which I'd like to share.
              >
              > 1. There are some limitations while using "setInterval":
              > 1.1. As far as I know, setInterval doesn't consider the time it
              > takes to execute the code block called. This means that if you have a
              > very short interval and a heavy (long/heavy) block of code, you may
              > not get the desired behavior (read as: things can go pretty messy).
              > Although scripting is executed as single thread, which assures that no
              > nasty interactions will occur, nevertheless the timing may messed up.
              > Please correct me if I'm wrong!

              I believe this is the reason for the lower update rates on Wuse. And, to
              some extent, this is what I'm trying to measure. The setInterval
              function is a likely approach for doing script-based animation, so I
              wanted to measure it to determine how well it will work for people.

              I probably do need some testing (later) to really push the limits to
              see where this approach breaks down. It's hard to tell people what to
              avoid if we don't know where the edges are.

              > 1.2. Firefox as a known issue [1] with this particular timing
              > mechanism. While it's pretty harder to reproduce using Firefox 3 than
              > in Firefox 2, it still applies...

              I'll look into that, thanks.

              > 1.3. I'd generally propose "setTimeout" as a timing mechanism
              > (called each time, immediately before returning), specially when the
              > time consumed in the called method isn't relevant (and, even so, one
              > can simply measure the time it took).

              I can run another set of tests using setTimeout, so we can compare the
              methods (in a separate report, probably). Since I'm not using the
              interval time to measure the interval, I think I'm okay on this.

              > 2. Couple of suggestions:
              > 2.1. In "What I'm Trying to Measure", maybe referencing (link to?)
              > the Firefox bug around the "setInterval" text wouldn't be a bad idea,
              > at least to point out this known limitation;

              I'll do that, thanks.

              > 2.2. In "Measurement Methodology", I also believe mentioning
              > (linking to?) the Batik bug report for the programmatic navigation
              > feature [4] would also be valuable - one can then see when and how was
              > it fixed (thanks for contributing it, as we're at it).

              Definitely. (I really should have thought to do that.)

              > 3. Few typos which I think you will appreciate:
              > 3.1. In "Rationale" [5], "surpised" --> "surprised";
              > 3.2. In "The Instruments Test" [6], "modification to" -->
              > "modification of" (?);
              > 3.3. In "The Wuse Test" [7], "hghest" --> "highest";

              So much for spell checkers.<grin/> Thanks, I'll correct these.

              > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=291386
              > [2] http://anomaly.org/wade/projects/svg/profiling/#what_measure
              > [3] http://anomaly.org/wade/projects/svg/profiling/#methodology
              > [4] https://issues.apache.org/bugzilla/show_bug.cgi?id=46072
              > [5] http://anomaly.org/wade/projects/svg/profiling/#rationale
              > [6]
              > http://anomaly.org/wade/projects/svg/profiling/#instruments_test_results
              > [7] http://anomaly.org/wade/projects/svg/profiling/#wuse_test_results

              Thank you very much for your help on this.
              G. Wade
              --
              There will always be things we wish to say in our programs that in all
              known languages can only be said poorly. -- Alan Perlis
            • Frank Bruder
              Great work so far. Just three comments: - You identify your platform and the user agents you ve tested, but since Batik is a Java application it would make
              Message 6 of 18 , Dec 3, 2008
              • 0 Attachment
                Great work so far. Just three comments:

                - You identify your platform and the user agents you've tested, but
                since Batik is a Java application it would make sense to also state
                which JVM version was used.

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

                - Finally I'd like to note that a normal distribution in fact is an
                absolutely unreasonable assumption for a variable which can not be
                negative. A gamma distribution is more like it.


                --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <gwadej@...>
                wrote:
                >
                > I have just posted a second draft of my "Results of Profiling Scripting
                > Animation in SVG" on my website at
                > http://anomaly.org/wade/projects/svg/profiling/
                >
                > I would appreciate any input from anyone who has the time to read and
                > comment on it.
                >
                > I will try to incorporate any comments (and some changes to the charts)
                > into a final version over the next few days/weeks. I also plan to put a
                > little time into styling, so it doesn't look quite so bland.
                >
                > I hope to add more specific profiling over time to compare different
                > aspects of scripting SVG.
                >
                > Any input would be appreciated.
                > G. Wade
                > --
                > All things are possible, given enough time and caffeine.
                > -- Danny Hoover
                >
              • G. Wade Johnson
                On Thu, 04 Dec 2008 06:12:30 -0000 ... (Smack head on table) You re right, I should have thought of that. I ll add it. ... I m not sure I understand your issue
                Message 7 of 18 , Dec 4, 2008
                • 0 Attachment
                  On Thu, 04 Dec 2008 06:12:30 -0000
                  "Frank Bruder" <redurbf@...> wrote:

                  > Great work so far. Just three comments:
                  >
                  > - You identify your platform and the user agents you've tested, but
                  > since Batik is a Java application it would make sense to also state
                  > which JVM version was used.

                  (Smack head on table) You're right, I should have thought of that. I'll
                  add it.

                  > - 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'm not sure I understand your issue here. The interval events for the
                  animation and the sampling are two independent timers (or at least they
                  appear to be). So the "order of events" doesn't appear to have any
                  relevance (unless I'm really misunderstanding you).

                  I actually use the Date.getTime() method on each call to the sampling
                  routine to measure the actual elapsed time between my samples. In a
                  previous life, I had seen how much the actual interval could vary
                  relative to the expected interval. I need to make sure that I am clear
                  about this in the text.

                  You are correct, I can't actually measure rendering in the script, so
                  I'm making the assumption that each update is a render. So, this is
                  a potential issue that I need to document.

                  > - Finally I'd like to note that a normal distribution in fact is an
                  > absolutely unreasonable assumption for a variable which can not be
                  > negative. A gamma distribution is more like it.

                  I stand corrected. My statistics is not what it used to be (and
                  possibly never was). Just to make sure, is a calculated standard
                  deviation still a useful measure of variation in a gamma distribution?
                  The main point of this assumption was to give me a measure of the
                  variability.

                  I really appreciate the time you have taken to read and comment on
                  this article.

                  Thank you,
                  G. Wade
                  > --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <gwadej@...>
                  > wrote:
                  > >
                  > > I have just posted a second draft of my "Results of Profiling
                  > > Scripting Animation in SVG" on my website at
                  > > http://anomaly.org/wade/projects/svg/profiling/
                  > >
                  > > I would appreciate any input from anyone who has the time to read
                  > > and comment on it.
                  > >
                  > > I will try to incorporate any comments (and some changes to the
                  > > charts) into a final version over the next few days/weeks. I also
                  > > plan to put a little time into styling, so it doesn't look quite so
                  > > bland.
                  > >
                  > > I hope to add more specific profiling over time to compare different
                  > > aspects of scripting SVG.
                  > >
                  > > Any input would be appreciated.
                  > > G. Wade
                  > > --
                  > > All things are possible, given enough time and caffeine.
                  > > -- Danny Hoover
                  > >
                  >
                  >


                  --
                  To vacillate or not to vacillate, that is the question ... or is it?
                • Erik Dahlström
                  ... 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.
                  Message 8 of 18 , Dec 4, 2008
                  • 0 Attachment
                    On Thu, 04 Dec 2008 07:12:30 +0100, Frank Bruder <redurbf@...> 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
                  • Helder Magalhães
                    ... The question is how sensitive is the human perception. Of course the screen refresh rate should take precedence but monitors (specially LCD, as CRT were
                    Message 9 of 18 , Dec 4, 2008
                    • 0 Attachment
                      > if you're not going to see the frames anyway,
                      > why should valuable CPU time be wasted rendering them?

                      The question is how sensitive is the human perception. Of course the
                      screen refresh rate should take precedence but monitors (specially
                      LCD, as CRT were already doing it for a while) are getting speedy (in
                      terms of Hz, in comparison to CRT) again.

                      Smoothness and flickering can be pretty tricky, as an interesting
                      writing about the fact [1] explains. My personal experience shows that
                      this is (apparently) not universal. For example I recall that, when I
                      was using CRT monitors, I could easily distinguish between 75 and
                      85Hz, although most of my colleagues couldn't. (Honestly, I can't
                      imagine how I was using a 60Hz monitor, even if this was about 10
                      years ago.) Similar effects using 3D action games: playing in a faster
                      machine achieving a higher frame rate made all the difference to me,
                      while most of my friends were not so affected (at least, according to
                      themselves)...

                      Just food for thought,

                      Helder Magalhães

                      [1] http://www.100fps.com/how_many_frames_can_humans_see.htm
                    • G. Wade Johnson
                      On Thu, 04 Dec 2008 15:28:40 +0100 ... 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
                      Message 10 of 18 , Dec 4, 2008
                      • 0 Attachment
                        On Thu, 04 Dec 2008 15:28:40 +0100
                        Erik Dahlström <ed@...> wrote:

                        > On Thu, 04 Dec 2008 07:12:30 +0100, Frank Bruder <redurbf@...>
                        > 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
                      • Erik Dahlström
                        On Thu, 04 Dec 2008 18:38:22 +0100, Helder Magalhães wrote: ... Yeah, that article is an interesting read. Anyhow, should you
                        Message 11 of 18 , Dec 5, 2008
                        • 0 Attachment
                          On Thu, 04 Dec 2008 18:38:22 +0100, Helder Magalhães <helder.magalhaes@...> wrote:

                          ...

                          > Smoothness and flickering can be pretty tricky, as an interesting
                          > writing about the fact [1] explains. My personal experience shows that
                          > this is (apparently) not universal. For example I recall that, when I
                          > was using CRT monitors, I could easily distinguish between 75 and
                          > 85Hz, although most of my colleagues couldn't. (Honestly, I can't
                          > imagine how I was using a 60Hz monitor, even if this was about 10
                          > years ago.) Similar effects using 3D action games: playing in a faster
                          > machine achieving a higher frame rate made all the difference to me,
                          > while most of my friends were not so affected (at least, according to
                          > themselves)...

                          Yeah, that article is an interesting read. Anyhow, should you feel the need for speed, we did include a preference (and a DOM API) for the target framerate in svg animations in Opera 10. The default is set to ~30fps, you can change the preference to higher (smoother animations but more resource-intensive) or lower (less smooth animations but less demanding processing).

                          The preference can be set through about:config (find it in the SVG section, or search for Target Framerate).

                          Cheers
                          /Erik

                          --
                          Erik Dahlstrom, Core Technology Developer, Opera Software
                          Co-Chair, W3C SVG Working Group
                          Personal blog: http://my.opera.com/macdev_ed
                        • Helder Magalhães
                          ... Great, this sounds really useful. :-) I m still getting acquainted with this new Opera release: didn t have the time to digg deep but only to have a quick
                          Message 12 of 18 , Dec 5, 2008
                          • 0 Attachment
                            > Anyhow, should you feel the need for speed, we did include a
                            > preference (and a DOM API) for the target framerate in svg
                            > animations in Opera 10. The default is set to ~30fps, you can
                            > change the preference to higher (smoother animations but more
                            > resource-intensive) or lower (less smooth animations but less
                            > demanding processing).

                            Great, this sounds really useful. :-)

                            I'm still getting acquainted with this new Opera release: didn't have
                            the time to digg deep but only to have a quick look at the performance
                            improvements and check for nasty regressions but in overall it looks
                            good (at least, from my preliminary tests). Congratulations on this
                            technology preview! BTW: why wasn't it announced on svg.org or in
                            other community sites? ;-)

                            Thanks for sharing,

                            Helder Magalhães
                          • Frank Bruder
                            ... What I mean is this: Consider the following code. setInterval(doSomething, 20); setTimeout(somethingElse, 1000); Nominally doSomething() would be expected
                            Message 13 of 18 , Dec 8, 2008
                            • 0 Attachment
                              --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <gwadej@...>
                              wrote:
                              >
                              > On Thu, 04 Dec 2008 06:12:30 -0000
                              > "Frank Bruder" <redurbf@...> wrote:
                              >
                              > > - 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'm not sure I understand your issue here. The interval events for the
                              > animation and the sampling are two independent timers (or at least they
                              > appear to be). So the "order of events" doesn't appear to have any
                              > relevance (unless I'm really misunderstanding you).

                              What I mean is this: Consider the following code.

                              setInterval(doSomething, 20);
                              setTimeout(somethingElse, 1000);

                              Nominally doSomething() would be expected to be called 50 times before
                              somethingElse() is called. If the execution of doSomething() takes
                              more than 20 ms then it can't be executed 50 times per second, but
                              calling somethingElse() after one second is still achievable. The
                              script engine could call doSomething() as often as is possible without
                              exceeding the nominal frequency, and call somethingElse() one second
                              after the call to setTimeout or as soon as possible thereafter.

                              But the scripting engine could alternatively manage the timer events
                              with respect to the nominal times, meaning doSomething() is called 50
                              times, and then somethingElse() is called, and this order is
                              maintained no matter what. This approach seems reasonable. Looking at
                              the code, it makes sense to think the author would expect
                              doSomething() to be executed 50 times before the call to somethingElse().

                              >
                              > I actually use the Date.getTime() method on each call to the sampling
                              > routine to measure the actual elapsed time between my samples.

                              Well then it's fine.

                              Another thing to consider is that the browser doesn't have to render
                              after each event.
                              Consider a video. If the computer is too slow to render it at the
                              frame rate it was recorded at, it can still render every frame,
                              slowing down the video, or it can skip frames in order to try to play
                              the video at its full speed. Slowing down the video brings the problem
                              that one then has to either slow down the audio too, or it gets out of
                              sync and out of context. Both these options are very undesired, so
                              typically the default setting of media player software is not to show
                              every frame.

                              With audio in SVG becoming available audio synchronized with animation
                              is a goal, and this would in some cases require frame rates to be
                              unaffected by scripted update rates.

                              > In a
                              > previous life, I had seen how much the actual interval could vary
                              > relative to the expected interval. I need to make sure that I am clear
                              > about this in the text.
                              >
                              > You are correct, I can't actually measure rendering in the script, so

                              I vaguely remember reading about plans for an event which would be
                              dispatched on rendering. I could be wrong now, but I think this was
                              going to be an upcoming feature in Firefox. Of course, a browser
                              specific feature could not be used for comparative testing.

                              > I'm making the assumption that each update is a render. So, this is
                              > a potential issue that I need to document.
                              >


                              Regards
                              Frank
                            • G. Wade Johnson
                              On Tue, 09 Dec 2008 03:51:07 -0000 ... Okay, I did understand you then. ... Provided, of course, that the times returned by Date.getTime() are correct and high
                              Message 14 of 18 , Dec 8, 2008
                              • 0 Attachment
                                On Tue, 09 Dec 2008 03:51:07 -0000
                                "Frank Bruder" <redurbf@...> wrote:

                                > --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <gwadej@...>
                                > wrote:
                                > >
                                > > On Thu, 04 Dec 2008 06:12:30 -0000
                                > > "Frank Bruder" <redurbf@...> wrote:
                                > >
                                > > > - 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'm not sure I understand your issue here. The interval events for
                                > > the animation and the sampling are two independent timers (or at
                                > > least they appear to be). So the "order of events" doesn't appear
                                > > to have any relevance (unless I'm really misunderstanding you).
                                >
                                > What I mean is this: Consider the following code.
                                >
                                > setInterval(doSomething, 20);
                                > setTimeout(somethingElse, 1000);
                                >
                                > Nominally doSomething() would be expected to be called 50 times before
                                > somethingElse() is called. If the execution of doSomething() takes
                                > more than 20 ms then it can't be executed 50 times per second, but
                                > calling somethingElse() after one second is still achievable. The
                                > script engine could call doSomething() as often as is possible without
                                > exceeding the nominal frequency, and call somethingElse() one second
                                > after the call to setTimeout or as soon as possible thereafter.
                                >
                                > But the scripting engine could alternatively manage the timer events
                                > with respect to the nominal times, meaning doSomething() is called 50
                                > times, and then somethingElse() is called, and this order is
                                > maintained no matter what. This approach seems reasonable. Looking at
                                > the code, it makes sense to think the author would expect
                                > doSomething() to be executed 50 times before the call to
                                > somethingElse().

                                Okay, I did understand you then.

                                > > I actually use the Date.getTime() method on each call to the
                                > > sampling routine to measure the actual elapsed time between my
                                > > samples.
                                >
                                > Well then it's fine.

                                Provided, of course, that the times returned by Date.getTime() are
                                correct and high enough resolution for the measurements I'm trying to
                                make.

                                Based on the input from this list, I'm trying to add a section
                                documenting the potential sources of error that I'm aware of and how
                                each might be mitigated.

                                > Another thing to consider is that the browser doesn't have to render
                                > after each event.
                                > Consider a video. If the computer is too slow to render it at the
                                > frame rate it was recorded at, it can still render every frame,
                                > slowing down the video, or it can skip frames in order to try to play
                                > the video at its full speed. Slowing down the video brings the problem
                                > that one then has to either slow down the audio too, or it gets out of
                                > sync and out of context. Both these options are very undesired, so
                                > typically the default setting of media player software is not to show
                                > every frame.

                                I hadn't really considered this one before, but now I'm going to at
                                least document it. Although I can reduce the effect of some errors, I'm
                                not sure there's a way to even detect this from the script.<shrug/>

                                > With audio in SVG becoming available audio synchronized with animation
                                > is a goal, and this would in some cases require frame rates to be
                                > unaffected by scripted update rates.
                                >
                                > > In a
                                > > previous life, I had seen how much the actual interval could vary
                                > > relative to the expected interval. I need to make sure that I am
                                > > clear about this in the text.
                                > >
                                > > You are correct, I can't actually measure rendering in the script,
                                > > so
                                >
                                > I vaguely remember reading about plans for an event which would be
                                > dispatched on rendering. I could be wrong now, but I think this was
                                > going to be an upcoming feature in Firefox. Of course, a browser
                                > specific feature could not be used for comparative testing.

                                That would be nice. we've recently seen that Opera may be providing a
                                way to detect the frame rate. I'd hate to have to do viewer-specific
                                code for looking at this and then try to generate something resembling
                                a useful comparison.<sigh/> So much for the quickie little project I
                                originally started.

                                > > I'm making the assumption that each update is a render. So, this is
                                > > a potential issue that I need to document.

                                I really appreciate the input. Several emails from this list have
                                shaken loose assumptions I needed to document and approaches I had
                                considered and discarded. Thanks to this list, I think the result will
                                be much more useful overall.

                                Thanks again for taking the time to review this paper and explain your
                                concerns (and for keeping me honest).

                                G. Wade
                                --
                                Always hold a grudge. Keeps the memory sharp. -- Hagar the Horrible
                              Your message has been successfully submitted and would be delivered to recipients shortly.