> > 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
