Re: [Frame Timing] Interaction with WebGL

It could depend on implementation, but that's the goal - anything that
generates content for the compositor (including user-driven actions like
scrolling or css animations) should get events. I don't see why WebGL
should be any different.

On Wed, Feb 11, 2015 at 10:03 AM, Nat Duca <> wrote:

> It should "just work" --- you will get main frame records for every frame
> that gets sent from js to the various browser's rendering subsystems. So by
> combining the frame timing API with a performance observer, you should be
> able to compute the frame rate not only of a page containing webgl, but
> also say a video tag as well. +mpb and +vmpstr in case I'm off base.
> On Tue, Feb 10, 2015 at 11:31 AM, Evan Nowak <> wrote:
>> Greetings,
>> I work with WebGL on a regular basis and I’ve had difficulty finding a
>> robust way to measure interactive framerates.  Timing intervals between
>> requestAnimationFrame callbacks provides decent results when in an
>> animation loop.  However, my application’s frames are event-driven, so
>> there isn’t a persistent rendering loop with which to measure framerate.  I
>> was excited when I encountered the frame timing api, because it looks like
>> it might be useful in the context of my problem.
>> After spending some time perusing the draft spec and the “explainer
>> <>”, I haven’t seen
>> any explicit mention of using the API for timing WebGL frames.  However, it
>> seems like this could be done, assuming the WebGL work done for one frame
>> can be correlated to a composite event.
>> Since I haven’t seen any explicit mention of WebGL, I wanted to email
>> this group for two reasons:
>>   1) To express interest in the API as a WebGL developer, so that you
>> know the interest is out there.
>>   2) To ask:  will the API, as it stands now, support timing of frames
>> with WebGL content?
>> Thanks,
>> Evan

Received on Friday, 13 February 2015 12:27:47 UTC