On 4 Aug 2009 19:33:05 +0100, Chris Young wrote: > On 4 Aug 2009 19:06:45 +0100, Chris Young wrote: > > > If you want to change it all to ABGR go ahead, just don't leave one > > bitmap format with a different byte order to all the others! > > btw, as an aside, the GTK version of NetSurf works fine and with the > right colours in Linux PPC (before the libnsgif change). If the > libnsgif change has upset that as well, then changing the byte order > so it is the same across the board may require changes in the GTK and > Framebuffer (SDL) platform code for them to continue to work correctly > on big-endian. > > I will check GIFs in a PPC compile of NetSurf GTK when I get chance to > reboot.
OK, as expected GTK NetSurf and the new libnsgif running on Linux PPC exhibit the same problem as on OS4 (GIFs are the wrong colour, everything else is fine). Looking at the GTK source, it appears that the colour primitives (which are ABGR on all platforms) have some bit-shifting "magic" in the platform code to make them work on big- and little-endian systems. Conversely, the bitmaps - which are RGBA on BE and ABGR on LE systems - are simply treated as RGB data by the platform code with no sign of endianess complications. If the GTK platform code can handle bitmaps that have the colour components "reversed" on BE/LE with no special handling, then I would say this is the correct way of doing things and it is the colour primitives that should be modified, not the bitmaps. Thoughts? Chris
