Still thinking about this. I still think that this extension can be simplified buy using QueryCounter only.
QueryCounter does not halves the number of queries, it just adds one (which does not matter as there will be 100s of queries usually)
On the other end, Begin/End will require twice the amount of API calls
100 time interval measure requires 200 begin/endquery calls
100 time interval measure require 101 queryCounter calls
On a use case, at rung time, I would want to first know the total time of the frame before looking into the detail ( that I can use to adjust parameter for the next frame). Total time is LastTimer – FirstTimer using QueryCounter, but much harder to get with Begin/EndQuery -> need to add ALL values.
I do understand the results between Begin/End and QueryCounter may be different, but it is not relevant as the spec says, it is just measurement errors that the application will ignore anyways
From: Ben Vanik <firstname.lastname@example.org>
Date: Tuesday, April 2, 2013 5:19 PM
To: Kenneth Russell <email@example.com>
Cc: Rémi Arnaud <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>
Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension
The two APIs provide two different values -- glQueryCounter gives you a timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are scenarios where both are interesting: if you're trying to get many elapsed times (such as timing draw calls/etc) then using the begin/end methods halves the number of query objects you need vs. trying to do it yourself via queryCounter. There's also the potential for the values retrieved from either to be different: the spec allows for different internal timing mechanisms to be used for both. I'm not sure if this is the case in reality, but it is allowed.
On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell <email@example.com> wrote:
Good question. As the primary author of the ANGLE_timer_query