[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #27782] drawInRect:fromRect:operation:fraction: doesn't work correc
From: |
Quentin Mathé |
Subject: |
[bug #27782] drawInRect:fromRect:operation:fraction: doesn't work correctly in a flipped view |
Date: |
Mon, 19 Apr 2010 16:33:55 +0000 |
User-agent: |
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6; fr-fr) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9 |
Follow-up Comment #16, bug #27782 (project gnustep):
NSCopyBits on Mac OS X has a behavior similar to -compositeToPoint, in
flipped coordinates the destination corresponds to the bottom left of the
image and not the top left unlike -drawInRect:. -compositePoint: ignores the
scaling so the drawing doesn't appear upside-down like -drawInRect:, however
the translation due the flipping is not cancelled so you must cancel it
yourself. That's why I had to similarly cancel it in -scrollRect:by:, since
the patch changes NSCopyBits semantic in Cairo to match Mac OS X.
Unlike what I expected at the time I wrote the code, this doesn't break the
other backends.
In flipped coordinates, the area where NSCopyBits draws is not the same on
Mac OS X than with the current backends (art, xlib, cairo). Cairo once patched
works correctly I hope now.
However based on the tests I did today, NSCopyBits source rect is still not
correctly interpreted, it seems there is no bounding rect computation
involved. To get the source rect in the window surface, on Mac OS X NSCopyBits
seems to do:
NSPoint srcOriginInBase = [sourceView convertPoint: [sourceView origin]
toView: nil];
NSRect srcRectInBase = NSMakeRect(srcOriginInBase.x + srcRect.origin.x,
srcOriginInBase.y + srcRect.origin.y, srcRect.width, srcRect.height);
That seems to fit well with the PScomposite doc I read. I haven't yet thought
about what would need to be changed in -compositeGState to get his behavior.
For NSImageCell, I check the control view is nil just to make the code more
explicit, but I'm fine with removing it.
I don't see any other way to draw the image correctly (for this case, the
Apple doc suggests to use a transform). The way it was implemented with a
negative height to flip the image orientation doesn't work on Mac OS X and is
not supported anymore with the patch.
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?27782>
_______________________________________________
Message posté via/par Savannah
http://savannah.gnu.org/