I don't have any personal issue with the API style either way, if you say callbacks are too slow, fine. Let's not do callbacks. I think that either API style has its pitfalls for beginners.On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik <firstname.lastname@example.org> wrote:The way I see it, the query API would work like this in a browser such as Chrome where rendering occurs in another thread (though it can be done similarly for other implementations):- user js runs init:- createQuery()- added to command buffer to send over to the gpu process- stashed in a 'query map' on the renderer side- user js runs frame:- beginQuery()- drawElements()- endQuery()- commands added to buffer, sent to gpu process- queryCounter()- returns the value of the renderer-side query object immediately - no blocking- gpu process:- run command buffer, see active timers, schedule them for processing- for each scheduled counter: query, if available then queue for sending back to renderer in a batch- renderer message from gpu:- for each updated query:- find in query map, set value- user js runs frame:- queryCounter()- returns the new value that was just setI don't understand how you could get accurate timings with just one query object for every frame. By the time you get to poll the value, there might have elapsed multiple frames, but you only have one state. querycounter doesn't capture the actual render time since it returns immediately without blocking. So wouldn't you have to allocate a new query object each frame? Isn't that also gonna be a killjoy for jerky animation?