On 10/14/2013 4:12 PM, Robert O'Callahan wrote:
On Mon, Oct 14, 2013 at 11:03 AM, Benjamin Smedberg
<benja...@smedbergs.us <mailto:benja...@smedbergs.us>> wrote:
Having this blocking interface will also support blocking shumway
on graphics rendering; there are a fair number of SWF files that
use an API to get a synchronous bitmap of their stage, which
requires a blocking call from shumway to the main thread even
after we get canvas-on-a-worker, which explicitly will not support
that blocking case.
I do not understand this. Current proposals for canvas-on-a-worker
allow reading the contents of a canvas into a bitmap. What's the
problem here?
Is canvas-on-a-worker a short-term project?
Also from reading the whatwg discussion, I thought you had proposed
.toBlob but not .toDataURI specifically so that the bitmap was not
synchronously available (the blob would mediate asynchronously fetching
the data).
It's still not clear to me whether with canvas-on-a-worker you were
planning on actually doing the graphics on the worker, or just batching
drawing instructions and sending them over to a separate graphics thread
to actually be executed.
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
