color problem for big endian fixes ??

[Bernd Roesch]

> 
> I think the situation is:
> 
> 
> On little endian systems the colour format is:
> 
>  + ABGR for everything.
> 
> On big endian systems the colour format is:
> 
>  + ABGR for everything that is not a bitmap, and
>  + RGBA for bitmaps.

yes
I verify with debugger and add a stop when the opaque blit on the startpage
is
done(blue netsurf image is blit).this is 
the colour value i get.alpha is on right side but the code assume alpha
value on left side.

0x3F6EFFFF

now when i set the stop in colour_to_pixel func  and modify for test this

#define FB_FRAME_COLOUR 0xFFDCDDDE 

i see in debugger register this values

0xFFDCDDDE 

for fill etc.all is same in 16 and 32 bit

the question is only if this much work to change netsurf that both
pixelorders are same ?.I look in png code, and i see no lines, that copy
data per byte.and when data are copy by pixelsize i think endian problems
cant happen

SDL have funcs sdl_maprgba to get pixel, and input of r,g,b,a value, but
that is slower.

> 
> Currently the framebuffer front end treats colours originating from
> bitmaps the same as it treats colours coming from everything else. This is
> fine on LE, but breaks on BE.
> 
> We could change the core to make the colour format more consistent, or we
> would change the framebuffer front end to handle colour conversion for
> colours coming from bitmaps differently. I'd prefer to do the former.
> 
> Also the framebuffer front end probably needs to cope with the actual
> framebuffer having any particular component order.
> 
Regards