Branch: krita-canvasrotation-silvioheinrich

[Dmitry Kazakov]

> But... hmm... the test like they are now will not compile and I'm afraid
> they never will :-/
> The changes I've done to the interface weren't done accidentally but by
> purpose.
> It wouldn't be right/possible to fit the new KisCoordinatesConverter class
> to the old class interface.
> I just fixed up the tests. They should compile now but won't pass.
> I only can change the tests so that they will pass (they will definitively
> not pass in the current state).
>

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.

 I should have renamed m_postprocessingTransform because it really has a
> different purpose then before.
> But I'm really sorry. I tried out other versions before and came to the
> conclusion that there is IMHO no other
> way of doing it.
> I think you know that matrix multiplication is not cumulative so it won't
> work (or just works to
> a certain limit) to have rotation, scaling and translation in separate
> matrices, when you need to track the relative
> change of one coordinate system, and then multiply them together in the
> end.
>

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.


> For further work i need that the krita canvas is able to rotate, zoom and
> mirror the image around an arbitrary point and this flexibility only comes
> with the code above.
>

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.


We can discuss it on irc, to make the things faster.

[1] - btw, i wonder whether setDocumentOffset() will be called right after
updateOffsetAfterTransform(). Will it?


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kimageshop/attachments/20110204/56407139/attachment.htm