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

Re: [Public WebGL] For review: ANGLE_timer_query extension



Yes, that's nasty.

It might be possible to work around this by saying that queries don't
change their state until the next requestAnimationFrame callback is
processed, but I agree that using callbacks instead would be simpler
and better guarantee correct usage.

Given the problems seen so far, I think we should either:

1) Rewrite the extension to use callbacks.

2) Remove all wording about when query results become available, and
leave things up to the user.

Thoughts? Other options?

Either way, prototyping the spec (in draft form, with vendor prefixes)
and seeing how well it works for various use cases is the only way
we're going to make an informed decision about the long-term direction
of the API.

Ben, Brian, in the spirit of avoiding premature optimization I suggest
we restructure the API to use callbacks and, if there are performance
issues with the prototype, try it again in polling form. What do you
think?

-Ken




On Thu, Apr 4, 2013 at 12:37 AM, Gregg Tavares <gman@google.com> wrote:
> So there's still another issue with polling. Even if we make it so you can't
> spin-wait and you can have to get result-available before checking the
> result you still end up with the issue that people will spam the browser by
> using
>
>     setInterval(checkQueries,0)
>
> In order to effectively spin wait on the queries. They'll do this because it
> will be faster on some platforms.
>
> I can certainly imagine code like this
>
>       function onRequestAnimationFrame() {
>             for each model {
>                   start occlusion query
>             }
>             id = setInterval(processQueries, 0);
>       }
>
>       function processQueries() {
>           for each query {
>                if (result-available) {
>                    if (not occluded) {
>                        draw;
>                    }
>                    remove query
>           }
>           if no more queries {
>              clearInterval(id)
>              requestAnimationFrame(onRequestAnimationFrame);
>           }
>       }
>
> On some implementations that may be faster even though is very bad for the
> browser.
>
> Again, with callbacks that's impossible. The code to process queries as fast
> as possible becomes
>
>        function onRequestAnimationFrame() {
>             for each model {
>                 start occlusion query with callback for model
>             }
>        }
>
>        function callback() {
>           if (not occluded) {
>              draw;
>           }
>           if no more queries {
>              requestAnimationFrame(onRequestAnimationFrame);
>           }
>        }
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, Apr 3, 2013 at 3:07 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>
>> On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares <gman@google.com> wrote:
>>>
>>> In no way did I suggest you would need a full frame to do this testing.
>>> If you want to know if a certain type of rendering is slow you can test your
>>> various types of rendering, off screen, at initialization time and find out
>>> which ones are slow.
>>
>> Unless you call gl.finish() which blocks you cannot test the time it took
>> to render something. You do not want to call gl.finish() because it blocks.
>> You may test performance characteristics up front, which tell you jack squat
>> how long things will actually take to render troughout the use of the
>> application. Timing how long something took to render, is the most accurate
>> way to figure out how long it took to render.
>
>

-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------