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

Re: [Public WebGL] For review: ANGLE_timer_query extension






On Thu, Apr 11, 2013 at 6:45 PM, Kenneth Russell <kbr@google.com> wrote:

On Thu, Apr 11, 2013 at 5:04 PM, Gregg Tavares <gman@google.com> wrote:
>
>
>
> On Thu, Apr 11, 2013 at 4:23 PM, Ben Vanik <benvanik@google.com> wrote:
>>
>> With a high level of confidence I can tell you that it won't be acceptable
>> to use callbacks for some of the scenarios this API is useful for and those
>> are the very same scenarios that make me really wish to see it implemented.
>> I still do not understand the desire to radically alter the way the API is
>> designed (from a way that can be used performantly to a way with (arguably)
>> questionable performance characteristics) when there are solutions to the
>> issues that don't require it.
>
>
> There aren't solutions as pointed out above.
>
> Devs will abuse an API anyway they can. If setTimeout(checkQuerys, 0) gets
> them a faster framerate they'll do it.

Here's a restructuring of the API to use callbacks.

  https://github.com/kenrussell/WebGL/tree/timer-query-callbacks

I'm not planning to push this branch into the repository. Thinking
about the use case where 1000 queries are issued in a frame, but
results from only a couple are fetched later, I agree that requiring
1000 event objects to be created and 1000 callbacks called is too
inefficient.


The more modern way to achieve this is with http://dom.spec.whatwg.org/#futures.  This still requires allocating an object per query but makes a lot of the syntax around it nicer.

- James
 

>> Instead of changing this API and implementing it (and realistic demos to
>> benchmark) twice I'd rather see work done on making readPixels async. That's
>> a call that's killing us today and would actually have a massive benefit in
>> being switched to a callback.

Personally I agree that there are higher priority things to work on
than this extension right now. If agreement is reached on a direction
for the API, I'll be happy to invest more time in it.

-Ken


>> On Thu, Apr 11, 2013 at 4:06 PM, Kenneth Russell <kbr@google.com> wrote:
>>>
>>> On Thu, Apr 11, 2013 at 2:13 PM, Florian Bösch <pyalot@gmail.com> wrote:
>>> > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell <kbr@google.com>
>>> > wrote:
>>> >>
>>> >> The problem is that even in this form, the query's result would still
>>> >> be retrieved with a polling API (getQueryParameter). This means that
>>> >> the spec would still have to include all of the caveats like
>>> >> getQueryParameter generating INVALID_OPERATION if the query hadn't
>>> >> been processed.
>>> >
>>> > Is that bad?
>>>
>>> Yes -- it means that badly written applications would still try to
>>> spin loop waiting for getQueryParameter to return a valid value. This
>>> must be specified to not work, and tested.
>>>
>>> >>
>>> >> To address this issue, each query would need a callback, which would
>>> >> receive the result as argument. There would be no way of retrieving
>>> >> the query's result separately.
>>> >
>>> > That's not really workable in usecases that Ben outlined. It's
>>> > thousands of
>>> > queries per frame. That's one important usecase, where you capture a
>>> > whole
>>> > hierarchy of timings and then drill down into what you want to know.
>>> > Even if
>>> > it wasn't seriously contest on performance, you can't "drill down" with
>>> > callbacks, it's not usable.
>>>
>>> The callback model can be converted into the polling model. The
>>> callback would just store the result on the query object, or in some
>>> sort of map. Then the tool can choose to display a subset of the
>>> results.
>>>
>>> The question of whether it would perform acceptably is the main issue.
>>> I am certainly concerned about this, but think we need to prototype it
>>> to measure.
>>>
>>> -Ken
>>
>>
>

-----------------------------------------------------------
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
-----------------------------------------------------------