[Public WebGL] Proposal: remove TIMESTAMP_EXT functionality from WebGL's EXT_disjoint_timer_query wrapper

Florian Bösch [email protected]
Wed Jun 8 01:16:07 PDT 2016

Build a performance picture of a frame where both deltas between two
checkpoints, as well as the absolute time of each checkpoint is available
(i.e. timestamps) is useful.

It is possible to emulate/shim timestamp queries purely in JS. This would
not be desirable for the usual reasons.

I'm against removing the TIMESTAMP_EXT functionality for the following

   - Precision bits are available to indicate not only precision but also
   support. Those bits are there for exactly that reason.
   - Timestamp functionality is useful
   - In the absence of platform native or browser emulated timestamp
   functionality, the precision bits can be used by those wishing to have
   timestamp functionality to plug in a pure JS shim.
   - In the absence of platform support, browsers may emulate timestamps
   with a non JS shim (that would probably be better than a JS shim) and they
   can communicate this via the precision bits.
   - Removing timestamp functionality removes the adapative
   upgrade/emulation as described above, and forces everybody in need of
   timestamps, to rely purely on shimming it in JS, forever, which is

On Wed, Jun 8, 2016 at 3:14 AM, Kenneth Russell <[email protected]> wrote:
> Developers have started using WebGL's wrapper for the
> EXT_disjoint_timer_query extension and have found that the TIMESTAMP_EXT
> queries aren't working well.
That timestamp queries will be problematic has been known since before the
extension was exposed. It is also what the precision bits are intended for.

Elapsed time queries are portable, and are the recommended way to gather
> timing information on the GPU.

And they can be used by an UA, if so desired, to emulate timestamps and
indicate that support with the precision bits.

not widely used yet, so the risk of breaking content is low.

I object to the removal not because of legacy breakage but because a useful
feature will be doomed to be JS-shimmed forever for those who need it.

On Wed, Jun 8, 2016 at 9:40 AM, Kirill Dmitrenko <[email protected]>

> Well, as I've written on webgl-dev-list, the fact that Chromium won't
> support TIMESTAMP_EXT renders it pretty much useless.
It is useful, where it works. And it can be shimmed in JS, if the precision
indicates non support.

> There is little to no sense to write one code for platforms that have
> timestamps and another one for ones that don't.
Yes there is, it's called a "shim".

> Especially considering absence of a way to feature-detect noop timestamps.
You can query the precision bits to figure out if timestamps are supported.

> If implementers don't want to support TIMESTAMP_EXT due to technical
> difficulties we should drop it from the extension spec.
The extension specification is intentionally extensible in its ability to
indicate support in the precision bits, so in order that emulations (in
drivers, UAs or JS) can be appropriately offered and the best
implementation rules over the next best.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160608/9892d973/attachment.html>

More information about the public_webgl mailing list