Translate the Path ADT to C.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. The path structure is a large memory burden.
2.
3.

What is the expected output? What do you see instead?

The path data structure is referenced in most drawing operations
up to the final 'stroke' or 'fill' operations which execute a 
painting method in the device.

If implemented in C, it could use the Xpost_Stack for extensible
lists, even representing the path in normal postscript syntax:
10 10 moveto 20 20 lineto 30 30 40 40 50 50 60 60 curveto closepath

The path implementation would need to interact with the (currently)
postscript-level implementation of the graphics state. Probably in a
similar manner to the device implementations, by adding a /Private
member to the gstate dict.

There should be speed improvements from this as well, since many 
postscript actions would be replaced by a single postscript action.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by luser.droog on 3 Dec 2013 at 4:48

[GoogleCodeExporter]

This is a performance issue.

Original comment by luser.droog on 3 Dec 2013 at 5:07

• Added labels: Performance

[GoogleCodeExporter]

This means all path operators: moveto, lineto, curveto, closepath, rmoveto, 
rlineto, rcurveto, strokepath, flattenpath, clippath, pathforall.

Original comment by luser.droog on 16 Dec 2013 at 11:45

[GoogleCodeExporter]

Started a topic in comp.lang.postscript to explore this idea.
https://groups.google.com/d/topic/comp.lang.postscript/dAwAN5x5goU/discussion

Original comment by luser.droog on 26 Dec 2013 at 7:32

[GoogleCodeExporter]

After much delay, I think the simplest thing to do is a straight translation. 
No need to design a new data structure just yet. Just re-writing the procedures 
in C will eliminate lots of round-trips through eval().

Original comment by luser.droog on 4 Sep 2014 at 5:12

[GoogleCodeExporter]

Translating moveto, lineto, curveto, close, arc, arcn, and flattenpath has 
reduced drawing times in testdraw.ps by 50%. Further improvement expected from 
translating the remaining path operators.

This doesn't address the memory footprint for the path structure which was the 
initial impetus here. But speed is good, right? Isolating the data structure 
should be a useful first step towards encapsulation and re-implementation. 

Original comment by luser.droog on 12 Sep 2014 at 6:07

[GoogleCodeExporter]

As discussed in this thread
https://groups.google.com/d/topic/comp.lang.postscript/dAwAN5x5goU/discussion
there is a possible simplification to the data structure by not modeling 
subpaths as separate dictionaries. Just keep the whole path flat. Then it maps 
directly to a stack representation.

So the final goal appears to be 2 levels of stacks:
- a stack of path-stacks to mirror gsave/grestore
- path-stack composed of numbers and {moveto/lineto/curveto/closepath} names

Original comment by luser.droog on 3 Jan 2015 at 9:05

[GoogleCodeExporter]

Original comment by luser.droog on 22 Feb 2015 at 9:05

• Changed state: Started

[luser-dr00g]

I think we're done with this one.