On Thu, Oct 31, 2013 at 12:36 PM, Robert O'Callahan <rob...@ocallahan.org>wrote:
> 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? > Well, at the very least we need the dimensions of the canvas buffer. We need to know if the context is lost too, but that can already happen anytime so that's not too bad. The dimensions live on the worker thread (which can update them) so we need to either lock and read them from the main thread or maintain a separate copy of the dimensions on the main thread and post messages to update them. If we do the first then it's possible for the dimensions the compositor sees to be newer than the last data we pushed to it. If we do the latter then the opposite is possible. Does the compositor care if the layer size and the data we push to it are not in sync? The CanvasLayer also wants the GLContext to do stuff with it. Not sure what we're going to do with that ... > 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. > That sounds reasonable ... it seems like just getting everything set up is the hard part. - Kyle _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
