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

Re: [Public WebGL] For review: ANGLE_timer_query extension

On Sat, Apr 13, 2013 at 3:57 AM, Florian Bösch <pyalot@gmail.com> wrote:
My stupid idea was that I mentioned alternative API approaches like callbacks at the beginning of this thread. I did that before really thinking trough Bens usecase. I've meanwhile thought about Bens usecase a lot, and I realized that the API proposed is pretty perfect and that I've proposed as fodder for discussion a lot of stupid things. The elegance of Bens proposal is that the API is fine grained, convenient to wrap and doesn't impose a particular way to handle timer queries onto a users application code.

I don't think that spinloops in themselves are an issue. We already have a working spinloop, it's called gl.finish.
Spinlooping without a synchronization command is an issue, because that can mutate to a deadspinloop. But this is relatively easy to safeguard against and throw an exception, which I'd consider a reasonable approach to migitate the issue and educate users on how not to use the API, without changing the API flavor.

The issue is designing an API that doesn't encourage using it wrong where wrong = breaks randomly. If left as is I believe it will be common to see code like this

      function render() 
           foreach query from last frame
                gl.getQueryParameter(gl.QUERY_RESULT_AVAILABLE); // don't check the result since we drew last frame

                var notOccluded = gl.getQueryParameter(gl.SAMPLES_PASSED); 
           for each model {

This code will appear to work on many systems but will break anytime the GPU takes a little too long. Examples of taking too long

    switching tabs
    launching another tab with WebGL
    launching another app
    switching apps
    running on a different GPU

That will be a hard bug to find. How will you know you have it? Launch some other tabs and pray it slows down your GPU enough that if you made this mistake you'll find it?

One of WebGL's explicit goals has been to adjust the api where necessary to avoid these kinds of issues. Shipping an API that is easy to get wrong in subtle ways that will be hard to know you got wrong seems like a bad idea.


I need this extension. Ben needs this extension. There are other people that need it. Other than safeguarding against erregious spinlooping it's pretty much perfect as is. Yes, it's not a _javascript_-y API, but making it more _javascript_-y doesn't improve the API. It just adds more overhead you have to take care of. Like hiding a handle, why's an integer a better handle than a handle? If you want to make it more _javascript_-y you can wrap your own utility code around it, which is what most users of the API would do anyway, because using it naked is nearly never really useful. Yes it's not a simple API, but it's also not a simple problem.

Can we stop bikeshedding on the API flavors and accept the API that ben proposed, with the provision that there is a solution to throw people out of spinlooping with a simple query counter reset since state change?