[Public WebGL] RequestAnimationFrame stops updating after hitting a breakpoint

Gregg Tavares (wrk) [email protected]
Wed Feb 9 10:11:59 PST 2011


On Wed, Feb 9, 2011 at 10:01 AM, Shy Shalom <[email protected]> wrote:

> > setTimeout you want to call at the beginning of the frame
>
> Can you elaborate why that is so?
> Is that considered common Javascript knowledge?
>

First off you should NEVER use setTimeout or setInterval for rendering now
that requestAnimationFrame exists. setTimeout and setInterval run even when
the user can not set the content like if it's off screen or in a hidden tab.
That can make browsing really suck as 30-90% of the machine is spent
updating something the user can't see. Hopefully with in a month or 2 all
browsers that support canvas will support requestAnimationFrame so user's
will stop going to pages that DOS their machine with setTimeout or
setInterval. I believe all browsers the support WebGL will support
requestAnimiationFrame. It's only IE that hasn't said if they have plans to
implement it.

As for why setTimeout needs to be at the top. It's because setTimeout fires
X milliseconds after you call it. Let's say you are trying to run at 60fps
or about 17ms.

function render()
   DoSomeRenderingThatTakes5-15msDependingOnMachine()
   setTimeout(render, 16);
}

That code will run at 21 to 31ms.

function render()
   setTimeout(render, 16);  // fire 16ms from now.
   DoSomeRenderingThatTakes5-15msDependingOnMachine()
}

This code will run at 16ms.

I suppose in the first case you could calculate how long your rendering took
and subtract that from the value you pass to setTimeout but since you
shouldn't be using setTimeout unless you have to this point is moot.



>
>
>
>
> On 9 February 2011 19:18, Gregg Tavares (wrk) <[email protected]> wrote:
>
>>
>>
>> On Wed, Feb 9, 2011 at 1:19 AM, Mikko Mononen <[email protected]>wrote:
>>
>>>
>>> Hi,
>>>
>>> Putting the call at the end of the render functions seems to fix the
>>> problem for now. Looks like as long as I put it after the last webgl
>>> call, breakpoints work ok.
>>>
>>> What is the idea behind calling it the first thing in the render
>>> function? Is the function requestAnimationFrame() documented somewhere
>>> (in relation to webgl too)? Is there a way to controls the max update
>>> rate? I'd be fine with 30Hz update, but it looks like the call back is
>>> called as fast as possible.
>>>
>>
>> If you are solely using requestAnimationFrame then it shouldn't matter
>> whether you put it at the beginning or end. Unfortunately in the case of the
>> wrapper at (
>> https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/common/webgl-utils.js) If
>> the browser does not support requestAnimationFrame then it falls back to
>> setTimeout. setTimeout you want to call at the beginning of the frame. So,
>> most of my samples call it at the beginning. Hopefully the debugging issues
>> will be fixed soon and the problem will go away.
>>
>>
>>
>>>
>>>
>>> --mikko
>>>
>>>
>>>
>>> On Tue, Feb 8, 2011 at 10:24 PM, James Robinson <[email protected]>
>>> wrote:
>>> > On Tue, Feb 8, 2011 at 4:10 AM, Mikko Mononen <[email protected]>
>>> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I just recently updated our code to use requestAnimationFrame()
>>> >> instead of a timer. I'm using the wrapper available from WebGL FAQ
>>> >> (http://www.khronos.org/webgl/wiki/FAQ). The wrapper finds and uses
>>> >> "webkitRequestAnimationFrame".
>>> >>
>>> >> If I hit a breakpoint inside the render function, step through some
>>> >> code and press continue, the screen stops updating (sometimes the
>>> >> browser aww-snaps too). I call requestAnimationFrame() the first thing
>>> >> when entering the rendering function. I'm using Chrome 10.0.648.18
>>> >> dev, OSX 10.6.6 and ATI HD2600.
>>> >>
>>> >> Is this a bug, or something I have to live with, and if so is there
>>> >> some workaround to this?
>>> >
>>> > This sounds a lot like a bug that I'm working on resolving right now.
>>>  I
>>> > hope to have a fix in the Chrome dev channel soon.
>>> > - James
>>> >>
>>> >>
>>> >> --mikko
>>> >>
>>> >> --
>>> >> Mikko Mononen, Software Engineer
>>> >> http://tinkercad.com - The unprofessional solid CAD
>>> >>
>>> >> -----------------------------------------------------------
>>> >> You are currently subscribed to [email protected]
>>> >> To unsubscribe, send an email to [email protected] with
>>> >> the following command in the body of your email:
>>> >> unsubscribe public_webgl
>>> >> -----------------------------------------------------------
>>> >>
>>> >
>>> >
>>>
>>>
>>>
>>> --
>>> Mikko Mononen, Software Engineer
>>> http://tinkercad.com - The unprofessional solid CAD
>>>
>>> -----------------------------------------------------------
>>> You are currently subscribed to [email protected]
>>> To unsubscribe, send an email to [email protected] with
>>> the following command in the body of your email:
>>> unsubscribe public_webgl
>>> -----------------------------------------------------------
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110209/0ce131af/attachment.html>


More information about the public_webgl mailing list