Branch: krita-canvasrotation-silvioheinrich

[Silvio Heinrich]

On 02/04/2011 06:42 PM, Dmitry Kazakov wrote:
> Well, if some tests fail, it means that some other subsystem may fail 
> because of changed guarantees. I think you need to write what 
> coordinate systems you have now and how your QTransform objects 
> reflect relations between these coordinate systems.
OK i maybe was a bit rash.
I reverted all changes and applied the commits again in another 
arrangement and I changed a few things.
Now the tests really do pass, yay :D.
And you where right I don't need to concentrate all matrices together 
but i still need the
flakeToPostprocessedFlake and postprocessedFlakeToWidget concentrated. I 
named it flakeToWidget.

Anyway I hope you can at least agree to the changes I made to the point 
of the commit:
b001ea167f55695b291154267386431c8396ea0b Removed scrollToCenterPoint method.
Up to this point i preserved all internals and did only interface 
improvements.
The last 3 commits then adding the feature to rotate and mirror the 
canvas around an arbitrary point and
making the rotation smooth.

> I'm sorry, but i didn't get what you mean. And Cyrille either. As far 
> as i know, the more multiplications you do on a single matrix, the 
> less precise it becomes. I think we can discuss it on irc or skype.
I don't think that we have to worry about precision here. Even single 
precision fp would be
sufficiently accurate enough.

> In the initial approach, all these types of actions were intended to 
> be done during Flake -> Postprocessed Flake coordinate system 
> conversion. The only flaw here was that during rotation around 
> arbitrary point, you would have to change scrolling values, so you 
> would have to change Postprocessed Flake->Widget conversion as well. 
> Is that the problem you meant?
>
> But, now, as far as i can see from the patch, you calculate 
> "documentOffset" value indirectly after the transform is done and then 
> just asks KoCanvasController to reset scrollbars with pan(). [1]  Do i 
> understand it right? If so, there is still no reason in keeping 
> postprocessing transformations in the same matrix with document offset.
I need a matrix that is in sync with the transformations the user caused 
and those transformations are at least
rotation, mirroring (scaling) and panning (translation).
The initial approch only tracked the rotaion and mirroring and then 
multiplied it with a translation (the offset) matrix when everything is 
recalculated.
But now i want to rotate/mirror the image araound an arbitrary point 
relative to the current position of the image
so i need to track the current position (the offset) with the 
flakeToWidget matrix too.
Btw, i don't see why this is such a problem. This is IMHO the common use 
case of transformation matrices.

But maybe I'm to fixated at my approach to see the reolution here. Maybe 
you can give me a hint on how I could implement this feature the right way.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110205/8440dc21/attachment.htm