[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] frame timing
At the very least the query API is coming in WebGL 2.0, and it seems like everyone is OK with the API format described in that spec. That gets us over one of the bigger hurdles, and may open the way for queries to be exposed to WebGL 1.0 as an extension.
I'm not sure about the rest of the arguments surrounding support or non-intuitive results.
On Saturday, January 18, 2014, Florian Bösch <email@example.com
A while back there was a discussion on introducing timer queries. Far as I recall, this discussion stalled on these points:
- About 50% of desktops support them and only a fraction of mobiles
They're non-intuitive on tiled renderers
- The implementations that exist may report garbage and/or slow things down considerably (unfit to deploy in production)
- Disagreement on the API format
Considering timer queries dead and burried, it would still be nice to have a way to measure per frame time that doesn't require gl.finish() (or mocking gl.finish with readPixels), that isn't hampered by tiled-rendering and that can capture performance regardless/beyond the 60fps cap (and without having to disable vsync browserwide).
I'd like to explore if there's a viable path to that goal:
- Disjoint timer queries (for mobile) and timer queries (for desktop) have some support. Would it be viable to use this capability in principle to achieve frame timing results?
- Would browser vendors be able to black/whitelist vendors/devices/drivers where timer queries behave anomalously?
- Lacking timer queries, or lacking their reliable functioning, would it be possible to achieve still relevant timings for a frame by other means for the UA?
- As an API to that functionality, would something like a WEBGL_frame_timer extension that just has one function like ext.getLastFrameTime() be satisfactory?