Austin Donnelly (austin@xxxxxxxx) wrote:
[scissors tool]
> I think I was probably the last person to do any major work on the scissors
> tool, and that was in 1999 to port it to the (then new) tile-based world.
>
> The code when I took it on was a "software Vietnam"; a complete mess. I had
> to read the SIGGRAPH paper it was attempting to implement before I could fix
> it, and believe me it left my hands much cleaner than I got it!
>
> There are two areas where it could do with improvement:
> - it doesn't handle tile-boundaries (it treats them as edges)
I am not sure if that is really the case. I some time ago looked at the
code and I believe that the broken behaviour for areas of very similiar
colors (i.e. preferring multiple of 45° lines instead of straight lines
between control points) is not correlated to tile boundaries and stems
from the fact, that the algorithm moves "pixel by pixel" without taking
the deviation from the straight line into account.
IIRC (been a time and the code definitely is nontrivial) the paper
specifies a function $f_D$ to have high costs for sharp changes in
boundary detection and I don't remember seeing an equivalent of this in
the code (might very well have missed it though).
Sorry for not being more specific about that.
> - the point editing interface sucks; I merely made the existing one work
> but it might be interesting to see if it could use the same code from the
> Path tool (that was always the plan)
That'd indeed rock. Intelligend Scissors could just be a path tool that
has a very crude way to calculate the segment between two control
points. The API might already support this (you can have custom stroke
types) but details would be needed to work this out (we'd then have
a dependency between the path and the associated drawable, since the
path needs the drawable to figure out its outline).
Bye,
Simon
--
simon@xxxxxxxx http://simon.budig.de/
