[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Branch: krita-canvasrotation-silvioheinrich
From: Silvio Heinrich <plassy () web ! de>
Date: 2011-02-05 20:58:49
Message-ID: 4D4DBA09.1050304 () web ! de
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
[Attachment #5 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 02/04/2011 06:42 PM, Dmitry Kazakov wrote:<br>
<blockquote
cite="mid:AANLkTimJqg6Xj-b=cLf9ugb9TifvmKhCBoPUdqoffyr7@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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.</div>
</div>
</blockquote>
OK i maybe was a bit rash.<br>
I reverted all changes and applied the commits again in another
arrangement and I changed a few things.<br>
Now the tests really do pass, yay :D.<br>
And you where right I don't need to concentrate all matrices
together but i still need the
<style type="text/css">p, li { white-space: pre-wrap; }</style><br>
flakeToPostprocessedFlake and postprocessedFlakeToWidget
concentrated. I named it flakeToWidget.<br>
<br>
Anyway I hope you can at least agree to the changes I made to the
point of the commit:<br>
b001ea167f55695b291154267386431c8396ea0b Removed scrollToCenterPoint
method.<br>
Up to this point i preserved all internals and did only interface
improvements.<br>
The last 3 commits then adding the feature to rotate and mirror the
canvas around an arbitrary point and<br>
making the rotation smooth.<br>
<br>
<blockquote
cite="mid:AANLkTimJqg6Xj-b=cLf9ugb9TifvmKhCBoPUdqoffyr7@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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. <br>
</div>
</div>
</blockquote>
I don't think that we have to worry about precision here.
Even single precision fp would be<br>
sufficiently accurate enough.<br>
<br>
<blockquote
cite="mid:AANLkTimJqg6Xj-b=cLf9ugb9TifvmKhCBoPUdqoffyr7@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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? <br>
<br>
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. <br>
</div>
</div>
</blockquote>
I need a matrix that is in sync with the transformations the user
caused and those transformations are at least<br>
rotation, mirroring (scaling) and panning (translation).<br>
The initial approch only tracked the rotaion and mirroring and then
multiplied it with a translation (the offset) matrix when everything
is recalculated.<br>
But now i want to rotate/mirror the image araound an arbitrary point
relative to the current position of the image<br>
so i need to track the current position (the offset) with the
flakeToWidget matrix too.<br>
Btw, i don't see why this is such a problem. This is IMHO the common
use case of transformation matrices.<br>
<br>
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.<br>
<br>
</body>
</html>
_______________________________________________
kimageshop mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic