Jon Phillips wrote:
Also, I have tried the trace function a couple of times and it brings my computer (toshiba 3490ct 700 mhz/p3/256mb laptop) to its knees and I had to abort before the procedure finished. Three possible things:
1.) Add a progress bar to show where the process is at...
That would not be too hard.
2.) Speedup the process
3.) simplify the complexity of the process somehow on an image. For example, if an image is too large, shrink the image.
I wonder if it's implemented correctly. Did you try the same image with the standalone potrace? (potrace.sf.net) If this still brings your computer to its knees, please send me the bitmap. It should not normally happen - in the past, this kind of behavior has typically exposed an implementation bug (i.e., an infinite loop of some kind) - or in one case, a compiler bug (some strange unsound loop optimization).
In my tests, potrace normally handles between 3 and 13 million pixels per second on reasonable images. On random noise, I just measured 0.17 million pixels/second (@1.7 GHz, for a 1000x1000 pixel image, produced by: ( echo P4 1000 1000 ; dd bs=1000 count=125 if=/dev/urandom)).
-- Peter