[Public WebGL] Some WebGL draft feedback
Tue Jan 12 18:42:43 PST 2010
On Tue, Jan 12, 2010 at 6:29 PM, Mark Callow <[email protected]>wrote:
> Hi Ken,
> Without explicit wait calls, every rendering call of every API needs to a
> test to check if some other context is currently rendering and if so, wait
> for it. This test will affect performance. It might only be a single if, but
> it will be in every rendering call. It also means that each rendering API
> needs to know about all the other APIs that can be used, which in turn means
> you have to update every API when a new one is added.
If an explicit wait is added to the API, what happens if the developer fails
to call it before rendering with a different context? Do they get an
exception or incorrect rendering results?
> And then there is Chris's point, that hiding the synchronization, makes
> people not realize the impact of their simple change to, e.g., draw a score
> on their WebGL game using a 2D API.
> Having explicit sync. makes it clear to everyone what is going on and keeps
> the APIs independent of each other.
> Kenneth Russell wrote:
>> All this is why I think our best way forward is (a) for getContext() to
>> return null when trying to create a second rendering API on implementations
>> that do not support simultaneous rendering, and (b) to have explicit sync
>> point calls (waitContext("xxx") as Mark proposes, or similar) for
>> implementations that do. I believe this gives support for simultaneous
>> rendering without the burden of mandating its support. It also allows more
>> flexibility in how simultaneous rendering is implemented.
> Agree on point (a). I don't think the explicit wait calls need to be or
> when the developer starts rendering with a different context. How would
> exposing them provide more flexibility to implementations?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the public_webgl