[whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
Glenn Maynard
glenn at zewt.org
Tue Mar 20 16:04:10 PDT 2012
On Tue, Mar 20, 2012 at 5:41 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 3/20/12 6:36 PM, Glenn Maynard wrote:
>
>> The drawing calls that happen after would need to be buffered (or
>> otherwise flush the queue, akin to calling glFinish), so the operations
>> still happen in order.
>>
>
> The former seems like it could get pretty expensive and the latter would
> negate the benefits of making it async, imo.
The latter just means that implementations aren't *required* to actually
buffer drawing operations.
It sounds like implementations are already doing the former, or want to,
from what James said. It's not inherently expensive, especially if the
input parameters to the drawing call are lightweight, which most canvas
calls are. OpenGL has always buffered commands like this. By buffering
the calls, you can push the actual drawing off to a thread and avoid
blocking the UI thread.
I don't see why it needs to block at all. At least in Gecko the
> putImageData basically just becomes a drawing command itself; you send it
> over to the graphics card and forget about it.
If you have previous drawing commands buffered, and you want to avoid extra
copies, then putImageData has to block until the buffered drawing commands
complete.
Avoiding that extra copy may not be worth the complexity, though.
what happens if the argument passed to putImageData is modified before
>> it's written?
>>
>
> You have to copy it, yes. Which you may have to do anyway, because
> imagedata is not premultiplied and for most drawing you want premultiplied
> data.
The question is whether you'd need to make a copy *synchronously*, before
putImageData returns. Manipulating the data you put into the image doesn't
have to happen until the actual blit occurs (and the two may happen in the
same pass).
--
Glenn Maynard
More information about the whatwg
mailing list