Unfortunately now that I have had time to think a bit harder, I
understand that there is a fundamental difference in how my initial
effort to implement a warp tool works compared to how the IWarp filter

Basically, when using the IWarp filter, and manipulating the preview
in its dialog, IWarp all the time has access to the complete original
drawable (well, it uses a preview-sized scaled version of it). Also,
the deformation vector array is built up and modified by each stroke
in the preview, and not re-initialized between strokes. The displayed
result preview is continuously based on pixels fetched from the
original drawable, not from the already warped preview.

In my current warp tool, on the other hand, each stroke (i.e.
invocation of a GimpWarp object, a subclass of GimpPaintCore) is
independent and reinitialises the deformation vector array. Also, it
continuously modifies the drawable being painted on from itself to
itself, if you understand what I think I mean...

So, how to solve this? Should the bookeeping of deformation vectors be
done per-drawawble by the GimpWarpTool object (a subclass of
GimpPaintTool) and not GimpWarp object? Ditto for a copy of the
original drawable. But when should this state then be discarded? Can a
GimpWarpTool object know when some other tool or filter is being used
on the drawable, and thus the warping data for that drawable should be

Hopefully this is a question with an obvious answer, and there is some
tool that already works like this...

Or is it really so that a warp tool, and the "filter brush" kinds of
tools that Ankh asks for, and all other nice cool things will need to
wait for a complete geglification?

Gimp-developer mailing list

Reply via email to