[Public WebGL] RequestAnimationFrame stops updating after hitting a breakpoint

Vincent Scheib [email protected]
Wed Feb 9 10:11:53 PST 2011


Re: targeting a max of 30Hz, in a distant email thread Greg suggested using
setInterval to make your requestAnimationFrame calls. The idea being that
the setInterval will be very cheap, and will queue your call backs no faster
than e.g. 30Hz, but the browser can limit them further.

-- My work and personal email are easily confused (@google.com or @gmail.com),
check before you write.


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?
>
>
>
>
> 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/dd7c975d/attachment.html>


More information about the public_webgl mailing list