The first go at this should make this a GPU-side copy. The initial version of this with share-groups isn't that hard, but it can get harder without them, since we have to migrate data between GLContexts. Eventually, we should be able to borrow these textures as copy-on-write, avoiding a copy if we don't need one, but this is significantly more complicated.

Unfortunately, we aren't using SkiaGL anywhere where share groups are supported, so I think we'll want to do the annoyingly-difficult solution in the first pass.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #1) > Unfortunately, we aren't using SkiaGL anywhere where share groups are > supported, so I think we'll want to do the annoyingly-difficult solution in > the first pass. Oh, I thought we were moving to SkiaGL everywhere. I guess we're still using something else on Mac?

(In reply to Jeff Gilbert [:jgilbert] from comment #2) > (In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #1) > > Unfortunately, we aren't using SkiaGL anywhere where share groups are > > supported, so I think we'll want to do the annoyingly-difficult solution in > > the first pass. > > Oh, I thought we were moving to SkiaGL everywhere. I guess we're still using > something else on Mac? Yeah, CoreGraphics still. I want to enable SkiaGL there, though.

There are 4 cases to handle: *2d(skiagl) to webgl *webgl to 2d *2d to 2d *webgl to webgl all of them should be easy if they use shared context, if not, it is still possible on B2G devices by sharing GrallocBuffer. If no shared context and not on b2g, we will need find some efficient way to do it.

(In reply to Chiajung Hung [:chiajung] from comment #4) > There are 4 cases to handle: > *2d(skiagl) to webgl > *webgl to 2d > *webgl to webgl These are basically all the same, because they involve copying the texture from one GL context to another. The 2d to 2d case should already work today. > > all of them should be easy if they use shared context, if not, it is still > possible on B2G devices by sharing GrallocBuffer. > > If no shared context and not on b2g, we will need find some efficient way to > do it. We have several methods of sharing textures, but all of that code is married to SurfaceStream (and SharedSurface) right now. If we could factor that stuff out in a sane way it would help a lot.

(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #5) > (In reply to Chiajung Hung [:chiajung] from comment #4) > > There are 4 cases to handle: > > *2d(skiagl) to webgl > > *webgl to 2d > > *webgl to webgl > > These are basically all the same, because they involve copying the texture > from one GL context to another. The 2d to 2d case should already work today. Yes, I just found it calls accessBitmap in skia and very fast now. Though I haven't trace how it make the source canvas flush all the pending draw calls while read it. > > > > > all of them should be easy if they use shared context, if not, it is still > > possible on B2G devices by sharing GrallocBuffer. > > > > If no shared context and not on b2g, we will need find some efficient way to > > do it. > > We have several methods of sharing textures, but all of that code is married > to SurfaceStream (and SharedSurface) right now. If we could factor that > stuff out in a sane way it would help a lot. One way to make SurfaceStream clear is make it a GL window (like SurfaceTexture in android), which I don't know how to do on windows/linux/MacOS. And decouple the GLScreenBuffer/SurfaceStream/GLContext/IPC: to make the user of GLContext create its own SurfaceStream then bind surfacfeStream into a GLScreenBuffer then build up a GLContext to use them. And create some callback in the SurfaceStream to let the user know there is a new frame to go. So it can IPC the Surface to the compositor or streaming the Surface into another Canvas. That is a huge refactoring, which I think need some more detailed plan before implementation.

By the way, the webgl to webgl case is a weird thing. Since WebGL have FBO, app can render to FBO first then using its color attachment as texture. The only need for it I think is for those YFLIP, and color space convert things. As a result, we generally need a intermediate surface to hold the flipped/converted data, so shared context may not help too much. Though we may keep the data in GPU, and flip/convert in GPU and use in another context if we make context shared. I will try PBO with a GPU Yflipper/color space converter/RBswapper, to see whether it helps. Any benchmark of these cases is welcome :)