[Public WebGL] Some WebGL draft feedback

Kenneth Russell [email protected]
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?

-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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100112/455abac7/attachment.html>


More information about the public_webgl mailing list