> I just found a in ggiUnmapPixel():
In what target or probably rather what rendering lib ?
> pixel-value: 16777215
> rgba (FF00,FF00,FF00,FFFF)
> ... instead of:
> pixel-value: 16777215
> rgba (FFFF,FFFF,FFFF,FFFF)
Note, that it is not guaranteed, that the map/unmap operation is invertible.
Actually it is never really invertible. This is simply impossible, as the
color data is 48 bits total, while the pixel data is 32 bits maximum.
You have probably used it on a 24 bit visual.
However it still is a minor bug, as it in deed should read FFFF in all
values, as the expansion rule is to expand bytes to words by doing
word=byte+(byte<<8); , as that gives the full dynamic range.
O.K. - I see it. it is in the color lib in color.c .
Now the question is: should we fix it ? The fix is nontrivial and will affect
the execution speed quite some. Crossblit will suffer from it quite a bit
...
As it is done now, it is guaranteed, that there are no cumulative errors, so
all that is lost is having a correctly scaled colorvalue when reading back
screen contents.
However we would at least have to document the behaviour ...
There are small glitches, though: Say we crossblit 16 -> 24 bit visuals,
the white on the 16 bit will read as f800 fc00 f800 and cause a
not-quite-white, with a greenish tint on the 24 bit visual.
I'm not quite sure if we should fix this ... Opinions ?
CU, ANdy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
