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

Re: [Public WebGL] For review: ANGLE_timer_query extension

How about this, when somebody starts polling a query you start a counter. By the Nth poll you throw an exception stating "spinners are usless you twit use gl.finish()" or something?

On Fri, Apr 12, 2013 at 11:08 PM, Florian Bösch <pyalot@gmail.com> wrote:
Why would you write a spinner when the behavior is well defined by gl.finish() that implies all previous server and client state has cleared the queue and your query is now ready to be read?

On Fri, Apr 12, 2013 at 11:04 PM, Gregg Tavares <gman@google.com> wrote:
People won't write spinners for timing. The will write spinners for occlusion queries.

Since it's the same API, the only difference is the enums passed in, it's important we don't expose the wrong API now and be stuck with an unsupportable or massively abused API in the future.

On Fri, Apr 12, 2013 at 1:54 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Fri, Apr 12, 2013 at 10:42 PM, Rémi Arnaud <jsremi@gmail.com> wrote:
This said I see no reason why someone could not decide to read first a query result that was in the middle of the frame, and then one at the end of the frame. For example in a multipass algorithm
It's a bad idea to do it, and I don't know either why Greg and others make such a fuss about it, it's not like people would write deadspinners for that.

So obviously you can't get the timing results for the remainder of the frame from the last synchronizing command (such as gl.finish).

But I don't see a reason why anybody shouldn't be able to use the queries before the last synchronizing command (and without polling). For example:

  1. lots of timers
  2. gl.finish()
  3. now work with all preceding queries
Because by the time gl.finish() returns it is guaranteed that all preceding timer queries are ready and filled.

Regardless of this fussy non-problem, you shouldn't do that for a couple reasons:

1) You need to call gl.finish() which synchronizes and slows everything down.
2) A single frame measurement as a deciding factor for a following rendering logic is just gonna make the code flap in the wind since execution times contain a fair deal of variance.

But if you really really want to do that, I don't think we should dictate that people can't.