[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 reasons:

On Wed, Jun 8, 2016 at 3:14 AM, Kenneth Russell <kbr@google.com> 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 <dmikis@yandex-team.ru> wrote:
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.