Support software WebRender with CompositorOGL on Android and Linux
Categories
(Core :: Graphics: WebRender, enhancement)
Tracking
()
Tracking | Status | |
---|---|---|
firefox88 | --- | fixed |
People
(Reporter: sotaro, Assigned: sotaro)
References
(Blocks 3 open bugs)
Details
Attachments
(1 file, 2 obsolete files)
It is nice if ASurfaceControl could be used for software WebRender.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
Assignee | ||
Comment 2•4 years ago
|
||
I confirmed that RenderCompositorSWGL could directly render to Android hardware buffer. But we need to convert from BGRA to RGBA by using gfxUtils::ConvertBGRAtoRGBA(), since android hardware buffer does not support BGRA format and RenderCompositorSWGL supports only BGRA.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 3•4 years ago
|
||
:lsalzman, :jrmuizel, is it possible to add RGBA support to RenderCompositorSWGL? Android hardware buffer does not support BGRA format.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•4 years ago
•
|
||
:mattwoodrow, :jrmuizel, is it OK to use CompositorOGL on android for Software WebRender like RenderCompositorD3D11SWGL? It uses CompositorD3D11. Software WebRender only supports BGRA. When all rendering is done only by Software, we need to convert from BGRA to RGBA.
When CompositorOGL is used, we could handle SurfaceTexture rendering simply.
Comment 5•4 years ago
|
||
I think there was a hope that we could avoid needing software webrender on Android at all, and ship hardware to 100% of our userbase.
If we have reason to believe that won't be possible, then I think using CompositorOGL should be fine (and is closer to what we current ship than RenderCompositorSWGL would be).
I think we could just rename RenderCompositorD3D11SWGL mostly to make a more generic type that targets the layers::Compositor API. There might be a few special cases for external compositor surfaces etc, but hopefully not a lot.
Assignee | ||
Comment 6•4 years ago
|
||
Thank you for the advice!
Comment 7•4 years ago
|
||
If necessary we might be able to make the SW compositor do the swizzle, but it's essentially turning every memcpy into a swizzle with the associated cost. If we #ifdef it at compile time for Android then it probably wouldn't be so horrible in terms of code-complexity, whereas it would be much harder to make compositing RGBA vs BGRA a runtime toggle. If we could rely on accelerated compositing on Android that may be a better scenario since Android hardware is already severely limited as it is.
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Comment 9•4 years ago
|
||
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 10•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 11•4 years ago
|
||
Comment 12•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Description
•