- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 20 Mar 2012 15:45:53 -0700
On 3/20/12 3:36 PM, Glenn Maynard wrote: > On Tue, Mar 20, 2012 at 2:08 PM, Boris Zbarsky<bzbarsky at mit.edu> wrote: > >> That would indeed be very nice. The question is what happens if drawing >> happens after the getImageData call... Or for that matter after the >> putImageData call (though I suspect there's less need for putImageData to >> be async). >> > 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. Webkit did land buffered drawing operations. When working with Flash (way back when) as a Canvas polyfill, buffered drawing made a huge difference. I doubt it has much of a performance impact now, except when rendering is done on some high latency pipeline (such as, perhaps, the GPU). The frustrating item here; the area where there may be a clear optimization or win is with video/webcam. We have to do: drawImage(video).getImageData() for each frame [of interest]. That one would be nice to have optimized. We can't use RoC's media stream processing API (workers) because it's for output, not input. We don't need the canvas to keep a copy of the image in buffer after the getImageData call. Beyond that case though, I doubt there's much to be done here -Charles
Received on Tuesday, 20 March 2012 15:45:53 UTC