[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Some WebGL draft feedback
On Wed, Jan 13, 2010 at 7:22 AM, Chris Marrin <email@example.com> wrote:
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.
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.
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:
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.