|Date:||Thu, 14 Jul 2011 11:02:22 +0200|
|User-agent:||Mozilla/5.0 (X11; U; Linux x86_64; de; rv:18.104.22.168) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|