So readback is definitely the easiest way to get started, but obviously it won't work long-term.
The right way is to create a new type of layer, a CanvasLayer, that encompasses a native shared surface shared between the WebGL task and the compositor. A "native shared surface" is the same OS-specific thing we use for texture sharing between the paint task and the compositor: it's an IOSurface on Mac and an X pixmap on Linux. The trickiest bit is passing the native shared surface through layout and into painting. We don't want to pass the surface directly; this will not work in multiprocess mode. Instead, we need to pass some sort of opaque ID and have the painting task be able to fetch the native shared surface from the ID. (Perhaps we could extend the image cache task, or create a sort of "canvas registry task" for this.) One issue is that we have to unconditionally layerize canvases for this, which violates the spec. I don't really see any easy way around that, though, and Blink does the same thing anyway. A word of caution: It can be tempting to use OpenGL's "shared context" feature in order to share a texture between the two threads without going through the OS-specific native shared surfaces. This is a performance trap, however, because shared contexts are nearly always implemented by wrapping all OpenGL operations in a mutex (effectively). This will cause WebGL use to jank the compositor: definitely undesirable! Patrick On Fri, Mar 13, 2015 at 6:15 AM, Josh Matthews <j...@joshmatthews.net> wrote: > It sounds likely that we'll have a student spend the summer working on a > basic WebGL implementation through the VALS Semester of Code ( > http://semesterofcode.com/). What's the right way to make that show up? > Presumably we don't want to do a readback thing like we did with the 2D > canvas (low-hanging fruit). > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
