2010/3/27 Krzysztof Kosiński <tweenk.pl@...400...>:
- Those interfaces have various implementations: ones that are not
bound to the XML, which work like current SPCanvasItems, and ones that do, which work like SPItems. This way we can maintain the CanvasItem / SPItem split while keeping the renderer oblivious of it, so that controls and SVG are rendered with he same high fidelity. (For example, right now control points are unaliased.)
And I honestly consider this lack of antialiasing an advantage - this makes it easy to visually distinguish objects from editing aids.
I think some cleansing could be done simultaneously:
- Get rid of NRObject. It's essentially an inferior clone of GType
which is used inside NRArena. 2. Get rid of remaining NR geometry code. 3. Get rid of SPCurve and replace it with a shared copy-on-write Geom::PathVector (which should be renamed to Geom::PathSequence). 4. Expand the SVGPathSink functionality in 2Geom, so that feeding paths to Cairo is done using this nice interface.
These are good objectives, if you can do this in addition to the cairo rendering it will be great. But for the canvas/arena unification I'm still unconvinced that it will give any advantages, and in any case it seems like a too big piece of work to stuff into one GSoC. Let's limit this year's work to cairofication and discuss this project later.