On Thu, Oct 31, 2013 at 5:28 PM, Kyle Huey <m...@kylehuey.com> 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? > What values do you need from the worker in order to create the layer? It seems to me that we should be able to create a CanvasLayer on the main thread that is sized to the canvas element. Then from the CanvasLayer we get some kind of thread-safe object (analogous to the ImageContainer of an ImageLayer) which can be handed to the worker in the WorkerCanvas. This object would support being one end of the surface stream for WebGL. You would feed a series of surfaces into it which could have different sizes and the compositor will size them to the layer. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w * * _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
