- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 20 Mar 2012 12:43:22 -0700
On 3/20/2012 12:08 PM, Boris Zbarsky wrote: > On 3/20/12 3:00 PM, James Robinson wrote: >> If we are adding new APIs for manipulating the backing directly, can we >> make them asynchronous? This would allow for many optimization >> opportunities that are currently difficult or impossible. > > You mean like not blocking the world on the readback? > > 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). I recommend we complete+use RoC's media processing API in addition to the CSS shaders proposal: http://www.w3.org/TR/streamproc/ https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html This would allow async post-processing via workers and less worry about putImage semantics. If we're looking for async getImageData purely for recognition, I think the current postMessage transfer semantics sped things up enough. getImageData and a subsequent draw call are always going to need to grab more memory. async isn't going to change that. -Charles
Received on Tuesday, 20 March 2012 12:43:22 UTC