bug-gnustep
[Top][All Lists]
Advanced

[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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]