[webkit-dev] RGBA8 and BGRA8 formats in WebKit

[Balazs Kelemen]

On 01/23/2013 01:43 AM, Allan Sandfeld Jensen wrote:
> 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.
>
>

Thanks, that was useful to me. I did not know that the internal format 
is byte order agnostic.