>  Do you really need to do it exactly the way the filter does it?
>  From your description, I don't really understand why your
>  current approach is less valid, or even why it will produce a
>  significantly different result.

It does produce a significantly different result. In my current code,
there is interpolation upon interpolation when calculating the new
pixels as the stroke proceeds, and the affected area gets more and
more blurred. In IWarp, even when updating the preview while stroking,
it is just one interpolation away from the original (scaled) preview

>  the system is set up
>  so that tools are automatically halted if a drawable is dirtied
>  while a tool is active.  (More precisely, while tool_control
>  is active.)

That sounds promising indeed. I do wish that there was some technical
documentation on how this all hangs together. Just trying to
understand by reading the code is a bit hard. When you say "tool", you
mean an object of a subclass of GimpTool, right, not an object of a
subclass of GimpPaintCore? That is one thing that was a unclear to me,
what is the proper division of tasks between a GimpTool and a

Gimp-developer mailing list

Reply via email to