980749 - Accelerate TexImage2D of canvases

Status: NEW

(Core :: Graphics: CanvasWebGL, enhancement, P3)

Description

[Kelsey Gilbert [:jgilbert]]

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.

Comment 1

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 2

[Kelsey Gilbert [:jgilbert]]

(In reply to James Willcox (:snorp) ([e-mail]) 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?

Comment 3

[James Willcox (:snorp) ([e-mail]) (he/him)]

(In reply to Jeff Gilbert [:jgilbert] from comment #2)
> (In reply to James Willcox (:snorp) ([e-mail]) 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.

Comment 4

[Chiajung Hung [:chiajung]]

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.

Comment 5

[James Willcox (:snorp) ([e-mail]) (he/him)]

(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.

Comment 6

[Chiajung Hung [:chiajung]]

(In reply to James Willcox (:snorp) ([e-mail]) 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.

Comment 7

[Chiajung Hung [:chiajung]]

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 :)

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jgilbert, could you have a look please?
For more information, please visit auto_nag documentation.