[Public WebGL] Some WebGL draft feedback

Mark Callow [email protected]
Tue Jan 5 19:10:24 PST 2010


Greg,

Simultaneous drawing by different APIs is not a problem only for "WebGL" 
(i.e. OpenGL). Lots of other APIs are implemented partially or fully in 
hardware these days: DirectX, OpenVG, etc. Adobe is even moving towards 
implementing Flash via OpenGL ES. Simultaneously using any such APIs 
requires synchronization points. In the example you gave, 
canvas.getContext would provide a synchronization point, but what is to 
prevent the application from keeping the context handles around in 
variables and arbitrarily switching between them? The spec would have to 
document the synchonization requirements and provide synchronization 
primitives which would make it more complex.

On the implementation side you previously stated that it is not that 
difficult to implement simultaneous rendering in a way that doesn't hurt 
performance for applications that do not use it. Actually, absent some 
up front indication from the application that it will stick to pure 3D, 
it will be impossible to do without loss of performance for _every_ 
WebGL application with some hardware/GL driver designs. So some API is 
necessary to allow the application to inform the implementation of its 
intentions up front requiring further spec. changes.

I think we should not support simultaneous rendering by different APIs 
at the first release. We can leave the door open so if there is great 
demand for the feature it can be added in a future release. A 
restriction now that canvas.getContext() destroys any existing context, 
thus preventing simultaneous rendering, can easily be relaxed in the 
future without breaking any applications.

Regards

    -Mark


Gregg Tavares wrote:
>
> The argument against multiple simultaneous contexts seems solely to be 
> that it is hard for webgl to support it. Outside of WebGL, it would 
> certainly not be hard to have multiple contexts if each just effected 
> a rectangular array of shared CPU side pixels. Each context would just 
> provide new API methods to add to ways you can effect those pixels. 
> Example:
>
> ... [snip]...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100106/96d4a5a9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callow_mark.vcf
Type: text/x-vcard
Size: 398 bytes
Desc: not available
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100106/96d4a5a9/attachment.vcf>


More information about the public_webgl mailing list