[webkit-dev] RGBA8 and BGRA8 formats in WebKit

[Allan Sandfeld Jensen]

On Wednesday 23 January 2013, Balazs Kelemen wrote:
> On 01/22/2013 05:14 PM, Zoltan Herczeg wrote:
> >>> Where in WebKit do you experience problems with color conversion?
> > 
> > As for me WebKit2 transmits BGRA images, which needs to be converted to
> > RGBA before it is uploaded to a texture on GLES 2.0. These conversions
> > seems computation heavy for certain animations, and I was wondered
> > whether do we really need to use BGRA here. It would be nice to invent
> > something to avoid that.
> 
> You explained the symptom but not the source of the problem. So, do you
> know _why_ do we have BGRA before the texture upload? If this is a
> software rendered image buffer, why can't we just use the appropriate
> format when doing the software rendering? Anybody?

Because it is a 32bit buffer of ARGB values. On a little endian CPU like i386, 
32bit ARGB is stored bytewise as BGRA. In Qt we always have 32bit ARGB values 
because that is the internal color format of the Qt renderer (QRgb). In the 
grand scheme of things it is probably easier up to upload BGRA textures than 
trying to double the rendering paths of QPainter to support RGBA.

A quick little overview of what I am talking about:

ARGB format aka RGBA32 (32bit ordered)

As 32bit math   8bit big endian 	8bit little endian
24-31bit: A 	    1.byte: A			1.byte B
16-23bit: R   		2.byte. R			2.byte G
 8-15bit: G   		3.byte. G			3.byte R
  0-7bit: B		   	4.byte. B			4.byte A

RGBA format aka RGBA8 (byte-ordered)

As byte format    32bit big endian 	32bit little endian
1.byte: R 	 	   24-31bit: R			24-31bit: A
2.byte: G   	   16-23bit: G			16-23bit: B
3.byte: B   		8-15bit: B			 8-15bit: G
4.byte: A		     0-7bit: A			  0-7bit: R

Ofcourse the confusion can be avoided if RGBA8 is only accesed bytewise, and 
ARGB only 32bit wise, but when uploading to textures or otherwise serializing 
it we need to deal with the mess.

Best regards
`Allan