Omari Stephens wrote:
> Hi, all
> I'm working on a patch which shifts the rotation grid so that a grid
> intersection always falls on the center of rotation. The simple use-case for
> this functionality is when doing a corrective rotation in a photo with a
> horizontal or vertical object. Maintaining an intersection on the center of
> rotation means that you'd _always_ be able to stick the center of rotation on
> one end of the straight object, align a gridline along the object, and be
> Currently, this is not always easily doable without futzing with the number
> My current rough-draft patch (against r28237) is up at:
> At the moment I have a few questions:
> 1) Let C be the coords for center of rotation, and TC be the coords for the
> transformed center of rotation. At times, it seems like TC is up-to-date and
> lags (such as when dragging the center of rotation with the mouse). But
> times, C is up-to-date and TC lags (for instance, when adjusting one of C's
> coords with the spinbox in the dialog). This makes it incredibly difficult
> make the offset always correct.
> I think this happens because gimp_transform_tool_grid_recalc() and
> gimp_transform_tool_transform_bounding_box() need to be called in differnet
> orders depending on where the canonical center of rotation coords are stored
> or TC).
> When you update the spinbox, the gimp_transform_tool_motion() callback calls
> gimp_rotate_tool_motion() (which sets C from the values in the spinbox), and
> then gimp_transform_tool_recalc(), calls ..._grid_recalc() and then
> ..._transform_bounding_box(). So, in this case, TC will be stale at the
> when ..._grid_recalc() is called (since TC is updated from C in
> When you move the center of rotation by dragging it with the mouse, however,
> seems that sometimes ..._transform_bounding_box() is called without an
> accompanying ..._grid_recalc() call, which means that C is stale but TC is
> up-to-date. In particular, when this happens, C is temporarily set to the
> center of the image, which I find incredibly confusing. I'm not sure how or
> this happens. Any suggestions for how should I fix this behavior so that
> correct in either case?
> 2) I want to only enable shifting when we're doing rotation (as opposed to
> shearing or scaling, for instance). This is as easy as clamping x_off and
> to zero in gimp_transform_tool_grid_recalc(). From that function, how do I
> determine if the transformation is a rotation?
> 3) The bounding box is drawn in a different function. I would like to avoid
> splitting the shift logic across functions (or duplicating it in both). Any
> suggestions on how to keep the bounding-box aligned with the grid (including
> shift offset), but still allow the bounding box to work when the grid isn't
> being calculated?
> 4) Any other questions, suggestions, or feedback?
I looked at this centre shift issue a year or so ago. You may be able to
find it the archive.
I found accumulated errors were leading to the image tracking around a
IIRC some improvement was made by someone else at that time but since
these base transformations will "soon" be migrated to gegl it was deemed
not worth improving the existing code base in this area.
I suggest you dig out that thread before investing too much effort.
Gimp-developer mailing list