Callbacks aren't really scalable for this kind of use.
They create too much overhead when trying to sample times.
They also break a lot of the usage patterns that make this API easy to use. I believe we've had this discussion before with respect to resource locks and I still stand by my assertions there: callbacks hurt performance, lead to spaghetti code (especially when it comes to trying to time hundreds+ things across frames/contexts),
and make the API less useful vs. the native version. Translating code that uses the API (via emscripten/etc) would also become much more difficult as the behavior is no longer the same.
Callbacks also don't handle a potential use case of this (which may never happen in a browser such as Chrome but would in Firefox/etc) where you want to query and check the value in a single frame. ex, start drawing and begin a query, draw, then try to get the query result in the same tick to decide what to do next.
Of course, advanced applications will try to pipeline this across frames, but sometimes you can't (due to potential latency issues/etc).I'm not sure I see a problem with that loop - you can shoot yourself in the foot many ways with code like that, and nobody should be writing that.
But taking the sledgehammer approach of changing the API and breaking valid scenarios hurts those who have a real use of the API. People writing bad code will continue to find ways to do so.
If it was a must that it not be allowed, breaking the contract here and forcing all query results be set in a separate JS tick would prevent spin loops while retaining the polling API. It'd turn loops like that into while(true);, which is probably fine. As I said, I doubt with the latency imposed by the separate GPU process as in Chrome that any results will be coming back in the same tick anyway.
On Tue, Apr 2, 2013 at 5:54 PM, Gregg Tavares <firstname.lastname@example.org> wrote:
It seems like queries should be based on callbacks.On Tue, Apr 2, 2013 at 5:19 PM, Ben Vanik <email@example.com> wrote:
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 <firstname.lastname@example.org> wrote:
Good question. As the primary author of the ANGLE_timer_query
extension, Ben Vanik should answer it.
Note that beginQuery and endQuery will definitely be needed in the
OpenGL ES 3.0 upgrade, since they support occlusion and primitive
On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi <Remi.Arnaud@amd.com> wrote:
> I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems
> like queryCounterANGLE alone can cover all use cases?
> -- Remi
> On 4/2/13 4:33 PM, "Kenneth Russell" <email@example.com> wrote:
>>The MapsGL team has requested for some time that the ANGLE_timer_query
>>extension be exposed to WebGL. The primary use case is to allow tools
>>to be written which identify performance problems in WebGL
>>Please review the proposal and send comments to the list:
>>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will
>>pull the query functions into the core. This extension becomes much
>>smaller when applied to that API version.
>>You are currently subscribed to firstname.lastname@example.org.
>>To unsubscribe, send an email to email@example.com with
>>the following command in the body of your email: