+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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev > -- /* Join Bluna Ratimonkey (漫画家) and build the real future for GNUstep ! */ [@"http://mus3.sourceforge.net"; setNeedsYourHelps:YES!!]; _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
