[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 5:04 PM, Gregg Tavares <firstname.lastname@example.org> wrote:
> On Thu, Apr 11, 2013 at 4:23 PM, Ben Vanik <email@example.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.
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
>> 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.
>> On Thu, Apr 11, 2013 at 4:06 PM, Kenneth Russell <firstname.lastname@example.org> wrote:
>>> On Thu, Apr 11, 2013 at 2:13 PM, Florian Bösch <email@example.com> wrote:
>>> > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell <firstname.lastname@example.org>
>>> > 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
>>> 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.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: