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

Re: [Public WebGL] For review: ANGLE_timer_query extension

Btw. can somebody present a good usecase for a deadspinner?

On Wed, Apr 3, 2013 at 8:40 PM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Apr 3, 2013 at 8:18 PM, Brian Cornell <bcornell@google.com> wrote:
1) Callbacks are less flexible because they are necessarily asynchronous. This means that it is impossible to get the results back before your content might be composited. In this case that might not be that useful or even possible on some browsers, but generally callback APIs make it hard to do something that might affect rendering.
Since the goal of the query API is to make it possible to get timing results without blocking (i.e. calling gl.finish()), I don't really see the utility in requiring an API semantic enabling blocking. If you want to block until something has finished, just call gl.finish(). If you want to time it, call performance.now(). The whole reason timer queries exist is because something is executed off in some process/driver in a rendering queue which you didn't want to block.
2) Callbacks can happen whenever the browser feels like it, even if you don't want them to. This makes it really hard to tightly manage framerate in a performance critical app. You could schedule all of your work very carefully to take up just about all of the free time in a frame, but the browser can then call 1000 callbacks and skip the next frame. There's no way to know how many callbacks are waiting so that you can leave time for them. And if you're really performance critical, your callbacks can't actually do anything, they have to just add something to a queue so that you can do the work somewhere where you are properly tracking the time.
A realistic usecase can't work with single timing values. You'd just flipflop between states every frame, and that wouldn't work. You will need to apply some averaging and statistics. To do that you will need to capture things in a buffer. Capturing things in a buffer, and then working with that buffer when you get a callback to requestAnimation frame, is exactly the same that you would do anyways. I don't see a difference of one preventing the other. I think either polling or callback properly handled amount to the exact identical same. One just seems a little less to write and less prone to abuse by beginners.

It can be said however that there is an assumption that you can do real work in event callbacks (also regarding clicks and so on). This is not really true, you should not do that. That's unfortunately another mistake, shared not just by beginners.
I agree that callbacks are very _javascript_-y, but not everything in _javascript_ is well designed for high performance apps.
requestAnimationFrame is a callback API and seems to work pretty fine.