bug in image compositing in -xlib

[Benhur Stein]

Hi!
I reported a bug in image drawing some days ago.
Well, I came back to it, and made a bad hack that corrects the problem.
Also attached is the program I used to test and a screenshot of
its execution in OS4.2 and GNUstep with back-xlib.
I couldn't try on -art because I get a compilation error (ftfont.m:82: parse error before 
"FTC_ImageDesc"), but I'm
pretty sure -art does not have this bug.

What the test program does is to draw a figure in two views (the left ones in 
the shot,
the top one is flipped and the bottom one is not) and then copy each of them to 
two
other views to the right, the first unflipped and the second one flipped.
The attached program draws a bit differently than the one I used to make the 
shots.

This bug can be easily seen using GWorkspace, in the "Tools" window, selecting 
a file
that can be open by many different programs. Some icons are drawn in the wrong 
position.

Depending on many things, the code xlib/XGGState.m
chooses to do compositing using copyBits:fromRect:toPoint: or 
_compositeGState:fromRect:toPoint:op:fraction:
Both methods draw in the wrong place half of the time (I executed the program
forcing one or the other method):
_composite... draws in the wrong place when the source view is flipped.
copyBits:... draws in the wrong place when flippedness of source and dest are 
not
the same.
the variable viewIsFlipped cannot be trusted (and I only found a reference to it
in the windows backend), so I accessed the ctm directly.
I know it is a bad hack, it is ugly, it should be solved differently, but it 
seems to work
and I do not have time to make a better solution...

Benhur

<copytest-GS-xlib.tiff><copytest-OS42.tiff><back.diff><GNUmakefile><testcopy.m>

copytest-GS-xlib.tiff
Description: TIFF image

copytest-OS42.tiff
Description: TIFF image

back.diff
Description: Binary data

GNUmakefile
Description: Binary data

testcopy.m
Description: Text document