Closed
Bug 1290643
Opened 9 years ago
Closed 3 years ago
Canvas with skiagl backend should use PersistentBufferProviderShared
Categories
(Core :: Graphics: Canvas2D, task)
Core
Graphics: Canvas2D
Tracking
()
RESOLVED
INVALID
People
(Reporter: ethlin, Unassigned)
References
Details
For now we use PersistentBufferProviderBasic for skiagl. We should try to use PersistentBufferProviderShared since there is some optimization.
Reporter | ||
Comment 1•9 years ago
|
||
For now canvas skiagl and webgl are CanvasClientSharedSurface which uses GLScreenBuffer to handle buffers. The GLScreenBuffer has front and back buffer and attaches the surface to GL framebuffer[1]. I have 3 proposals for the next step.
[1] Take GLScreenBuffer as a coordinator to GLContext in PersistentBufferProviderShared. PersistentBufferProviderShared will have a GLScreenBuffer and request new SharedSurfaceTextureClient from it. We may need to open some interfaces in GLScreenBuffer.
[2] Let PersistentBufferProviderShared have the ability to handle GLContext and the related SharedSurface. We need to do something similar to GLScreenBuffer in PersistentBufferProviderShared.
[3] Keep the original CanvasClientSharedSurface/GLScreenBuffer architecture. We can try to apply PersistedRect or dirty rect to it.
:nical, do you have any idea?
[1] https://hg.mozilla.org/mozilla-central/annotate/6608e5864780589b25d5421c3d3673ab30c4c318/gfx/gl/GLScreenBuffer.cpp#l485
Flags: needinfo?(nical.bugzilla)
Comment 2•9 years ago
|
||
For skia-gl we have two distinct cases:
* We can rendr into a gl texture that can be shared it with the compositor directly without copy
* We have to do a read-back before sending to the compositor.
In the second case it is pointless to use PersistentBufferProviderShared since the whole point of this buffer provider is to let canvas draw directly into the shared texture.
In the first case, I don't know the SharedSurface flow well enough to give a precise answer, but I am hoping that we can somehow wrap the shared gl texture in a SharedSurfaceTextureClient and do the same thing as in the non-skia-gl code path.
From a quick glance at CanvasClientSharedSurface, we seem to be copying the texture (through CloneSurface or readback) in many cases. I am not sure which of these cases correspond to which configurations and if we can get away with not copying, it would be interesting to find out.
If in the end we can only have few users with skia-gl and zero copy at the same time, I don't think it is worth optimizing that path specifically. It would be interesting to find out.
Flags: needinfo?(nical.bugzilla)
Comment 3•3 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months.
:lsalzman, could you have a look please?
For more information, please visit auto_nag documentation.
Assignee: demo99 → nobody
Flags: needinfo?(lsalzman)
Updated•3 years ago
|
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(lsalzman)
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•