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

Re: Report on SVG Viewer Performance

Expand Messages
  • Frank Bruder
    ... What I mean is this: Consider the following code. setInterval(doSomething, 20); setTimeout(somethingElse, 1000); Nominally doSomething() would be expected
    Message 1 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 2 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.