Re: [Public WebGL] Some WebGL draft feedback

[Kenneth Russell <kbr@google.com>]

On Tue, Jan 12, 2010 at 6:29 PM, Mark Callow <callow_mark@hicorp.co.jp> 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?

-Ken

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.

Regards

    -Mark

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 should be exposed to _javascript_, though. They can be called under the hood when the developer starts rendering with a different context. How would exposing them provide more flexibility to implementations?

-Ken