[Public WebGL] Some WebGL draft feedback

Kenneth Russell [email protected]
Wed Jan 13 11:46:20 PST 2010


On Wed, Jan 13, 2010 at 7:22 AM, Chris Marrin <[email protected]> wrote:

>
> On Jan 12, 2010, at 8:00 PM, Mark Callow wrote:
>
> >
> >
> > Kenneth Russell wrote:
> >>
> >> 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?
> > Incorrect rendering. The exception checks would have the same performance
> and tentacle-spreading issues I raised before.
>
>
> Good point. So I've just jumped into Vlad's camp. It would be better to
> make sure (now or in the future) that we have an efficient path to get bits
> from one Canvas element to another. If we get the semantics right, I think
> it would even be possible for implementations to perform operations on a set
> of pixels with multiple APIs without copying. All we would need is some sort
> of "use" semantics rather than the "draw" semantics we have now with Canvas
> elements.
>
> This is something I have been thinking about for Video elements as well.
> "Use" semantics would allow a hardware video buffer to be used as a texture
> source (given the proper support in the implementation. For instance:
>
>        gl.useTexture(videoElement);
>
> Now whenever this texture is used as an image source the implementation
> would need to make the video frame available. On some impementations this
> would be pretty much the equivalent of texImage2D (copying pixels). But on
> some a hardware video buffer could be made available. The same is true of
> Canvas elements.
>
> But all of this should be left till the second release of the spec.
>

I agree that a proposal such as this should be left for a future revision of
the spec. It seems to me that it would introduce even worse synchronization
problems than supporting multiple rendering contexts on a single canvas.

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20100113/ae6d7c31/attachment.html>


More information about the public_webgl mailing list