It is nice if ASurfaceControl could be used for software WebRender.

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.

:lsalzman, :jrmuizel, is it possible to add RGBA support to RenderCompositorSWGL? Android hardware buffer does not support BGRA format.

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

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.

Thank you for the advice!

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.

Yep, what Matt said.

https://hg.mozilla.org/mozilla-central/rev/c2a11810933e