1390397 - Make WebGL context compatible to RGB10_A2 format for ANGLE3173

Status: RESOLVED FIXED

(Core :: Graphics: CanvasWebGL, enhancement)

Description

[Michael Leu[:Lenzak](UTC+8)]

ANGLE lands a patch 4 months ago, which introduces RGB10_A2 as default framebuffer format. And it is not compatible to our framebuffer configuration which is BGRA8888, leading to failures when performance bufferswapping when preserveBuffer is on after updating ANGLE to chromium/3173

Comment 1

[Michael Leu[:Lenzak](UTC+8)]

It is more complicate than we thought.

In older ANGLE, our framebuffer are always BGRA8888 so we can blit front and back buffer without issue.

Newer ANGLE introduced RGB10_A2 in this changeset.
https://github.com/google/angle/commit/62a416d5940621e62d37daa0c3c723febf45d6fb

As a result, we will get an ANGLE surface with RGB10_A2 when we get a buffer from ANGLE, and it should be always RGB10_A2, however, when we are blitting front and back buffer, the front buffer will have BGRA8888 so it fails in ANGLE's validation.

Only WebGL1.0 context have this issue.

WebGL2.0 has a different backend in blitframebuffer so it have no issue.


I tried to revert this changeset, but it will hit another assertion here because the internalFormat will be LOCAL_GL_RGB instead of LOCAL_GL_RGBA.
https://dxr.mozilla.org/mozilla-central/source/gfx/gl/GLContext.cpp?q=GLContext.cpp&redirect_type=direct#2969

It seems that newer ANGLE will omit Alpha channel if we pass surfaceCaps with alpha = false.

I removed the assertions but the format inconsistent still present, albeit GL_RGB8_OES vs GL_BGRA8 instead of GL_RGB10_A2 vs GL_BGRA8.

I am not sure whether we should change gecko or ANGLE to address this issue.

Hi Jeff, do you have any suggestions?

Comment 2

[Kelsey Gilbert [:jgilbert]]

With ANGLE, we should always ask for alpha:true.
We shouldn't get RGB10_A2 if we ask for r:8,g:8,b:8,a:8.

Comment 3

[Michael Leu[:Lenzak](UTC+8)]

Fixed by forced enable alpha when choosing SurfaceCaps to create ANGLE context.