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 _______________________________________________ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
