Re: bug in image drawing

[Benhur Stein]

Alexander Malmberg wrote:
> This is tricky, but the behavior of compositing has been discussed
> before:
> 
> http://mail.gnu.org/archive/html/gnustep-dev/2002-09/msg00013.html
> http://mail.gnu.org/archive/html/gnustep-dev/2002-09/msg00051.html
> 
> If this doesn't clear it up, tell me and I'll try to provide a better
> explanation (with pictures and stuff).

I've put some figures below, with what I have understood from those.
source has a rectangle 123 with 1 being the origin point;
destination has an x in the destination point
and the resulting 123 where the figure will be after the copy.
Is it the way NSCopyBits should work?
It is not the way it is working now on -xlib. in the second case, 
123 starts in x and goes down, that's why things appear offset when
GraphicCompositing is NO.

Source       Destination
unflipped     unflipped
  3             3
  2             2
  1            x1

unflipped     flipped
  3             3
  2             2
  1            x1

flipped     unflipped
  1            x1
  2             2
  3             3

flipped     flipped
  1            x1
  2             2
  3             3



> I'm not really familiar with how -xlib handles this (it seems to have
> very limited handling of transforms), but -gui is correct afaict (I have
> no problems, regardless of GraphicCompositing, with back-art).

Unfortunately, I have never been able to use back-art in my system
(gentoo linux on x86), X dies when I run the first gnustep app.

I can't see an implementation for copyBits in back-art. Does it use the
one in xlib?

Benhur