- From: Glenn Maynard <glenn@zewt.org>
- Date: Tue, 20 Mar 2012 18:04:10 -0500
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
Received on Tuesday, 20 March 2012 16:04:10 UTC