[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
I didn't think of precision bits. With them as a feature detection mechanism it is OK to rely on shims in my opinion. So, I'm agreee to leave TIMESTAMP_EXT be.
08.06.2016, 11:16, "Florian Bösch" <firstname.lastname@example.org>:
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:
- 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 undesirable.
On Wed, Jun 8, 2016 at 3:14 AM, Kenneth Russell <email@example.com>
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 <firstname.lastname@example.org>
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.
Yandex Maps Team