On Sat, 2 Dec 2000, Andreas Beck wrote:
> > I just found a in ggiUnmapPixel():
>
> In what target or probably rather what rendering lib ?
I found it on a 24bit visual. Maybe it is somewhere else, too.
> > 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.
Right.
> 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 .
Yes. I also posted a patch on this list. See my other mail with the
"[PATCH]"-prefix in the subject.
> 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
> ...
??? How can a wrong color-value affect cross-blitting?
> 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.
Not at all. When you convert the values into another colorspace (e.g. HSV), you
get the wrong values...
> 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 ...
Sure.
> Opinions ?
See above.
Christoph Egger
E-Mail: [EMAIL PROTECTED]
