You probably don't want to draw into the layer at all. So the main
thread should have a canvas layer and the worker thread should draw into
a CanvasClient (I think, the canvas layer will have a dummy canvas
client too which doesn't do much). This is similar to how async video
works where it is called the ImageBridge protocol. You should extend
ImageBridge to work with canvas, I think. This would mean the main
thread is not involved with rendering at all. Nical is the
ImageBridge/async video expert and he can tell you more and correct my
errors.
Nick
On 31/10/2013 5:28 p.m., Kyle Huey wrote:
One thing that's come up that we're not quite how to deal with for
OMT<canvas> is
how to modify GetCanvasLayer. Our problem here is that the context
here lives on the worker thread, and presumably we need to construct
the layer on the main thread, but creating that layer requires data
that also lives on the worker thread.
We obviously can't block the main thread on a synchronous call to the
worker, and we can't just lock around the values because that will
break run to completion semantics on the worker (e.g. if the worker
never yields, changes in the canvas size shouldn't take effect).
I think the right thing to do is probably to ship the values from the
worker to the main thread asynchronously as they are updated on the
worker (once the worker yields/etc) and create the layer using those
values. How often do we create layers? It would be a shame if
rendering straight from the worker to the compositor were blocked by
the main thread due to layer creation.
Anything else we should be thinking about here?
- Kyle
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
