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

Re: [Public WebGL] For review: ANGLE_timer_query extension

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.

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.

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

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.