I think an IWarp tool would require mechanisms in GIMP that don't
exist yet as none of the current tools, even if superficially similar
(like the smudge tool) requires them. Also, the exact way an IWarp
tool should behave should be specified before one starts coding on
it;) Yeah, getting input on how the corresponding functionality UI
works in PS might be useful, or not. GIMP is not supposed to be a PS

Should using an IWarp tool mean entering a separate "mode" where you
then have to "apply and exit" it when done? That is somewhat ugly,
isn't it? Or should an IWarp tool automatically do the final
application of the displacement map that has been built up during
subsequent IWarp "brush" strokes and whatnot when another tool is
selected and used? Will that be unbearably slow? In a non-destructive
GEGLified future, that probably doesn't matter much as the calculation
of updated actual image pixels can be done in the background (as long
as the preview is correct enough), or something.

I quote my comment in the bug mentioned, "The smudge tool is
inherently quite different from what an IWarp tool would be. Each
stroke of the smudge tool immediately affects the pixels the brush
touches. There is no memory of previous strokes. In IWarp, on the
other hand, what happens when you stroke is that the displacement map
gets updated, and the effect on the *original* pixels from when the
tool was started has to be recalculated. (At least, something like
this is what I recall from when I was hacking on making IWarp a

Gimp-developer mailing list

Reply via email to