I don't see any connection between the question and the answer.
All was asked is the ability to get result from a query in the middle of a frame, without habing to wait for the last query to be available. Therfore, in the 'current' API, first poling a query and in the same frame later, poling a another timer.
With the proposed API, creating 2 sets of queries, and having 2 callbacks.
So just to restate here's some pseudo code
.. gl calls
.. gl calls
+ Callback/polling for timer(A) and prev
.. Potentially do something about timerA in this same frame
+ callback/polling from last timer
The example above show that more than one poll per frame can be useful, in particular if any reaction to the result is expected to happen in the same frame
- RemiFrom: Florian Bösch <email@example.com>Date: Fri, 12 Apr 2013 22:54:16 +0200To: RÃ©mi Arnaud<firstname.lastname@example.org>Cc: RÃ©mi Arnaud<email@example.com>; Ben Vanik<firstname.lastname@example.org>; email@example.com<firstname.lastname@example.org>; Kenneth Russell<email@example.com>; Gregg Tavares<firstname.lastname@example.org>; Public Webgl<email@example.com>; Brian Cornell<firstname.lastname@example.org>; Glenn Maynard<email@example.com>Subject: Re: [Public WebGL] For review: ANGLE_timer_query extensionOn Fri, Apr 12, 2013 at 10:42 PM, Rémi Arnaud <firstname.lastname@example.org> 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:
- lots of timers
- now work with all preceding queriesBecause 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.