On Tue, 09 Dec 2008 03:51:07 -0000 "Frank Bruder" <[EMAIL PROTECTED]> wrote:
> --- In svg-developers@yahoogroups.com, "G. Wade Johnson" <[EMAIL PROTECTED]> > wrote: > > > > On Thu, 04 Dec 2008 06:12:30 -0000 > > "Frank Bruder" <[EMAIL PROTECTED]> 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 ------------------------------------ ----- 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/
