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 does. 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 discarded? 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? --tml _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
