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 lookalike. 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 tool.)" --tml _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
