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

Re: [Public WebGL] For review: ANGLE_timer_query extension





On Fri, Apr 12, 2013 at 6:24 PM, Rémi Arnaud <jsremi@gmail.com> wrote:
I guess I am confused to what is the 'current' API. As I recall, the 'current' API had an issue with pooling queries before they are available -
 Pooling queries isn't a problem.

the one I proposed does not.
It does pool queries just the same, it's just taking control away from a user to individually address and group them in any meaningful datastructure that matters to users.

Not at all. The main difference is that the user cannot ask for a query before they are available. User can only access the 'results' from the parameter passed into the callback.

I don't understand how the proposed API takes control away from the user to individually address a query, it actually provide a way to group queries. User can query any number of timers in the callback and save this in whatever data structure it want. 
 
The proposed API does not put the burden of allocating each individual timers to _javascript_
It's not a burden.
 
, but the 'current' API does.
It's not a problem.

 Ok, still the proposed API avoid the need to user to do 1000s of allocation, 1000s of garbage collection. I thought this would be of interest in the concept of a real time (1000s times per frame) use.

 
Yet both API enable the use of 1000s of timers
The current API enables to individually address single queries, that a user holds, in data structures that matter to them, which is not a list.

The proposed API does exactly the same, except that the queries are grouped and available as a (whatever you want to be) array, list…. They are individually addressed in the callback, the user can put the result it whatever data structure it want….
 
The proposed API provide the user with the capability to group timers together in sets, associated with their own callback.
There can be thousands of sets in hundreds of hierarchical levels.

 Sure, there can be hundreds of sets. The proposed API enable grouping the queries in sets, provides callback (event) when a given set if available, avoid pooling issue as mentioned in this email thread

Verdict: stop inventing problems that don't exist and make the API even less usable. 
 Sorry, but I beg to differ. I see the proposed API more usable, faster, solving the reported issues, and working in all the use cases that were described.