[pygtk] Advice for Debugging Coordinate Translation (my own and cairo's)
Pietro Battiston
me at pietrobattiston.it
Sat Sep 10 18:21:30 WST 2011
Il giorno ven, 09/09/2011 alle 12.42 -0400, Jamie Bliss ha scritto:
> This might be considered off-topic, but this is the closest I could
> think of. I need help trying to track down a bug.
>
> I have an application I'm working called cropper. (Screenshot:
> <http://imgur.com/iIUCu> Source:
> <https://github.com/astronouth7303/cropper>) It's basically a tool
> that lets you crop an image in multiple ways at once.
>
> It's currently suffering from a number of major bugs, but the big one
> that's really bothering me atm is zooming.
>
> The "workspace" is a single custom widget (ImageSpace, in
> imagespace.py) wrapped in a ScrolledWindow. It has the ability to zoom
> in and out on the content (by setting the zoom property, 1.0 is
> normal, 2.0 is twice as big, 0.5 is half as big). The problem is that
> when zoom != 1.0, it doesn't transform coordinates between the image
> space and widget space correctly.
>
> For calculations and such, I define two methods (img2widgetcoords and
> widget2imgcoords) for this transformation. (The image is always
> centered in the widget.) But for drawing, I'm using cairo's
> transformation methods.
>
> As far as I can tell, these two methods should produce the same
> results. But somehow, something's wrong. It's exhibited when creating
> new boxes, in the calculation cache system, and looking at output I
> made specifically for debug (the spot that widget2imgcoords calls
> (0,0) isn't where the upper-right corner of the image).
>
> Does anyone have any experience they can offer on this? Is this just a
> disconnect between cairo's methods and mine? Am I just doing something
> wrong?
>
Hello Jamie,
I just gave a very brief look at your code, and have a very brief
suggestion: have you considered using directly Cairo matrix objects to
manage coordinates changes?
That's what I did - notice my problem was sligthly different from yours,
and that code is probably in non-working state - for instance here:
git clone git://pietrobattiston.it/spilla
(if I remember correctly, for instance "transform_point" used in
spillamod/operations.py) and it was very useful - I can always make
drawing bugs, but once I draw, I know clicks are in sync with the
drawing.
> Thank you,
You're welcome, good luck!
Pietro
More information about the pygtk
mailing list