[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] For review: ANGLE_timer_query extension
Callbacks aren't really scalable for this kind of use. They create too much overhead when trying to sample times. They also break a lot of the usage patterns that make this API easy to use. I believe we've had this discussion before with respect to resource locks and I still stand by my assertions there: callbacks hurt performance, lead to spaghetti code (especially when it comes to trying to time hundreds+ things across frames/contexts), and make the API less useful vs. the native version. Translating code that uses the API (via emscripten/etc) would also become much more difficult as the behavior is no longer the same.
Callbacks also don't handle a potential use case of this (which may never happen in a browser such as Chrome but would in Firefox/etc) where you want to query and check the value in a single frame. ex, start drawing and begin a query, draw, then try to get the query result in the same tick to decide what to do next. Of course, advanced applications will try to pipeline this across frames, but sometimes you can't (due to potential latency issues/etc).
I'm not sure I see a problem with that loop - you can shoot yourself in the foot many ways with code like that, and nobody should be writing that. But taking the sledgehammer approach of changing the API and breaking valid scenarios hurts those who have a real use of the API. People writing bad code will continue to find ways to do so.
If it was a must that it not be allowed, breaking the contract here and forcing all query results be set in a separate JS tick would prevent spin loops while retaining the polling API. It'd turn loops like that into while(true);, which is probably fine. As I said, I doubt with the latency imposed by the separate GPU process as in Chrome that any results will be coming back in the same tick anyway.