Re: NSView boundsRotation

[Bluna Ratimonkey]

+1 no ads intended. But actually I don't quite understand this. Like
bounds should always be treated like a rectangle in global coordinate?
But they allowed skew in the transformation while enforcing RSX+T
model? what's the formula of this? RMX+T ?

On Thu, Jul 14, 2011 at 4:02 PM, Fred Kiefer <address@hidden> wrote:
> 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.
>
> Fred
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev
>



-- 
/* Join Bluna Ratimonkey (漫画家) and build the real future for GNUstep ! */
   [@"http://mus3.sourceforge.net"; setNeedsYourHelps:YES!!];