[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

NSView boundsRotation

From: Fred Kiefer
Subject: NSView boundsRotation
Date: Thu, 14 Jul 2011 11:02:22 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv: Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11

I spend some time to find out why the NSView_bounds_scale.m test is failing and now I am pretty sure I have the solution, although I don't like it.

The problem here is the boundsRotation. Apple seems to have a very specific concept here. The value returned by that method (and used internally by methods like setBoundsRotation:) isn't what you would expect. I think they store this value directly for the NSView and adjust it only from the rotation methods. That is, this value has nothing to do with the actual rotation value of the current bounds transformation matrix, as we implemented it in GNUstep. The important difference is when you combine a scale operation with a rotation. Independent of the order of these operations Apple comes up with the same rotation value, whereas GNUstep will end up with different values.

As there is no use in saying that our results are mathematically correct, I suggest that we move over to the Apple way of doing things and start storing the rotation in the NSView. This saves us one expensive call to atan2() as well.

The same change may also be needed for the frame rotation, but I will have to write more test code to verify this.


reply via email to

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