On Mon, Oct 14, 2013 at 10:16 PM, Benjamin Smedberg
<benja...@smedbergs.us> wrote:
> 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?

>From talking to Kyle, it sounds like getting WebGL into workers is
much closer than getting all of Context2D, too. Specifically, we need
text rendering to work, because we have to be able to render device
fonts. Into bitmaps. Synchronously, because everything else would be
way too easy.

To reiterate, we have two non-negotiable requirements for enabling
off-mainthread usage of Shumway:
- synchronous drawing to canvas, including text rendering
- synchronous two-way communication with surrounding JS, with
arbitrarily-recursive calls between page JS and Shumway

>
> 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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to