Update based on feedback from Jeff, re: possible ClientStorage issues on Mac. I suggested we be prudent about how aggressively we switch a platform, and perhaps tie it to shipping WebRender on that platform to some users already (so that we gain some reward for the risk).

Putting this one under the more general endianness meta-bug.

Update with the fact that we are only doing this for Android. There was some confusion as to how ambitious we needed to be, and although it doesn't really change the scope of the necessary work, for now we are only expecting to target Android for shipping, and Linux on a best effort basis for testing purposes. It may be desirable to convert Linux for shipping as well, if only to get better continuous integration / testing converage.

Martin, do you have any thoughts on the possibility of making Linux use RGBA everywhere instead of BGRA, with respect to Linux specific issues? X11, Wayland paint points, etc. Also, the possibility of using BGRA or RGBA instead of ARGB on big endian systems? (It would certainly be a better supported configuration if we didn't bother producing ARGB, and worst case did a swizzle just before emitting data to the backend, which is better than it being incorrect as it is today. Not willing to put much effort into this however. As far as I know, we mainly produce ARGB on big endian because of Cairo.)

Hi,

I don't know about X11, Karl may know more, ni? him.

As for Wayland, only RGBA/RGBX formats are supported by default and everything else is optional and for instance my box (Intel i7/with GT 520 gfx card) supports only RGBA/RGBX for shm rendering. Other formats may be used through DMABUF which is slow.

Err, sorry, correction. Wayland uses WL_SHM_FORMAT_ARGB8888 which is equal to gfx::SurfaceFormat::B8G8R8A8 and WL_SHM_FORMAT_XRGB8888 which is gfx::SurfaceFormat::B8G8R8X8. So BGRA/BGRX is used by Wayland.

If I may bikeshed, I'd suggest avoiding use of RGB in the name of something that is often BGR. OS_COLOR and OS_COLOR_ALPHA may be options.

I assume color orders used in the proposal are byte orders rather than orders in 32-bit words.

(In reply to Andrew Osmond [:aosmond] from comment #6)

Created attachment 9108193 [details]
RGBA architecture proposal, v3

Update with the fact that we are only doing this for Android. There was some confusion as to how ambitious we needed to be, and although it doesn't really change the scope of the necessary work, for now we are only expecting to target Android for shipping, and Linux on a best effort basis for testing purposes.

It may be desirable to convert Linux for shipping as well, if only to get better continuous integration / testing converage.

I'm not clear what you mean by conversion for shipping.

I assume conversion to BGR(A) only for internal formats would merely involve removal of fast paths for R5G6B5_UINT16. It's use is limited enough that a decision to use the WindowSurfaceX11Image slow fallback path seems reasonable.

Conversion to RGBA for shipping would require swizzling in the ubiquitous case for drawing to the display.

Martin, do you have any thoughts on the possibility of making Linux use RGBA everywhere instead of BGRA, with respect to Linux specific issues? X11, Wayland paint points, etc.

X11 (and Wayland as indicated by Martin) are usually going to want BGR(A), but the WindowSurfaceX11Image slow fallback path attempts to handle conversion by delegating to gfx::DrawTarget::DrawSurface(). I don't know how well that works in practice. This should be fine for testing.

Also, the possibility of using BGRA or RGBA instead of ARGB on big endian systems? (It would certainly be a better supported configuration if we didn't bother producing ARGB, and worst case did a swizzle just before emitting data to the backend, which is better than it being incorrect as it is today. Not willing to put much effort into this however. As far as I know, we mainly produce ARGB on big endian because of Cairo.)

PictStandardARGB32 is ARGB on big-endian systems and so I assume swizzling would be required for conversion to screen format if BGRA or RGBA were used for internal formats. (There are no 32-bit "standards" with other orders.) Perhaps there are some tricks that can be used to convert between XRGB and RGBX, but I don't know whether they would pay off with the misalignment.

I can't comment on whether supporting a single byte order or a single word format is more likely to produce expected results on big endian systems.

Pixman formats describe the color order in the word, not byte order.

Before I open a new ticket: May I ask, what the status of this issue is?

The work done so far breaks big endian machines (or rather, breaks it even with the current set of patches we have, e.g.: bug 1504834)

The image decoders now seem to have the data in LE format, so we see blue overlays over most image types again, as well as various other color-issues.

Is this to be expected, as this is still work in progress?

My main concern is the next ESR-version, so I'm personally fine with the non-ESR versions inbetween being broken.