On Tue, 04 Aug 2009 18:28:52 +0100, John-Mark Bell wrote:

> On Tue, 2009-08-04 at 18:15 +0100, Chris Young wrote:
> > On Mon, 03 Aug 2009 22:07:06 -0000,  wrote:
> > 
> > > URL: http://source.netsurf-browser.org?rev=9027&view=rev
> > > Log:
> > > Stop utterly insane palette entry population.
> > > Palette entries are always ABGR, regardless of platform endianness.
> > > This change probably breaks big-endian platforms which, under the
> > > old approach, had palette entries of the form RGBA (assuming I
> > > understood the code correctly).
> > 
> > Yes it does, and it totally breaks NetSurf* as GIFs now have a
> > different byte order to every other bitmap.
> > 
> > Can we either change all the bitmap outputs to ABGR or (preferably)
> > leave them all as RGBA please?
> 
> Colour component ordering is orthogonal to endianness, so the current
> mess within NetSurf (and, apparently, libns*) whereby bitmap component
> ordering depends on the CPU's endianness is insane.

I do kind of agree with this, but component ordering is linked to
endianness to some degree, and the screen format here is "big endian"
(ARGB), and I take it on little endian systems the screen format is
reversed (BGRA or ABGR).  Although I stand to be corrected on this, it
seems sensible to keep the format as close to the destination format
as possible to save unnecessary bit-shifting.

> When I suggested making bitmap component ordering the same as that of
> colour primitives (i.e. ABGR), you said that the Amiga bitmap APIs
> couldn't handle it and that you'd prefer that we left it in its current
> inconsistent state. Has your position changed here?

No, my position hasn't changed.  I can probably work around it as I
can dump images into native BitMaps from pretty much any byte order,
and I think there is only one function I use which needs ARGB or RGBA
data at the moment (and it isn't speed critical).

> RGBA isn't an option, as RISC OS simply cannot cope with that at all.

When I said RGBA I meant leave it endian-dependant, but I realise
you'd rather not do that.

At the moment libnsgif (and the linkage within NetSurf) is outputting
a different component order to JPEGs, PNGs etc.  That's more of a mess
than having a different component orders for big- and little-endian
systems.

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!

Chris

Reply via email to