This change has broken some things on Windows. Here is a screenshot from our application showing the problem, with an image displayed in a tableView (the table here contains only one row):
When I roll back this change, it displays as it should:
It's hard to tell from this particular image, but the image itself is not flipped, just displaced. Hopefully that's enough for you to tell what's going on. If you need additional information please let me know.
Doug
On Jun 1, 2010, at 6:00 AM, Quentin Mathé wrote:
Hi,
I just committed a patch I have been working on for a while. See bug report https://savannah.gnu.org/bugs/?27782
This should solve various differences between GNUstep vs Cocoa image drawing when Cairo is used, especially with -[NSImage drawInRect:fromRect:operation:fraction:] or similar.
For the Cairo backend, this method should now give the same result than Cocoa when the destination is flipped, rotated or scaled. The scaling between the inRect and the fromRect should also work correctly. Various border cases such as passing NSZeroRect are now handled in a way that matches Cocoa.
The performance should also be much better when you draw a small source rect from a big image, since we only manipulate the source rect area rather than the whole image now. We also do not create an intermediate image to apply the graphics context transform, we just delegate that to Cairo, so this should improve performance a bit too.
Cairo also had various issues with -compositeGStateXXX and -DPSimageXXX. This means NSImage composite/dissolve methods now behave correctly, NSCopyBits too and -[NSView scrollRect:by:] should work in non-flipped coordinates unlike previously.
The Cairo backend unlike other backends should now match the Cocoa image drawing behavior exactly. This should be visible if you play with NSAffineTransform a lot. For example, in a flipped view, concat a rotation, a scaling and a manual flip transform, then draw an image with by scaling it with inRect and fromRect.
Art, Xlib and Winlib backends shouldn't have changed much since they still use the old code path. This code path is much more complex than the Cairo code path that delegates as much as possible to the backend rather than trying to handle things like rotation on the Gui side.
I tested Cairo, Art and Xlib, they work fine for me with GSTest, Gorm and various Étoilé applications. I haven't tested the Winlib backend, so I'm interested to know if it still works correctly.
I'll commit the test application I have been using to compare Cocoa vs GNUstep behavior soon.
Although I tried to simplify the code as much as possible, there are still some cleaning to do and also things to be worked out. e.g. NSCopyBits doesn't behave the same on GNUstep and Cocoa when you give it a view gstate.
Cheers,
Quentin.
_______________________________________________
Gnustep-dev mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/gnustep-dev