2010/4/8 Krzysztof Kosi?ski :

On 4/7/10, Krzysztof Kosi?ski wrote:

Here's my Cairo rendering proposal. I made it public so that all people can comment.

(linking to archived mail instead of full quoting original message) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33871

To me this looks like a good approach for a cairo based renderer for inkscape, since I maintain GEGL which could possibly considered an alternative I'll post some thoughts on whether GEGLs rendering model could possibly fit into inkscape. (Note, until the last paragraph I list thing that are similar to what is needed, but at the moment probably would be a much worse option than what you have outlined). GEGL deals with many or most of the concerns of an interactive SVG canvas. And at least the long term it should be an eligible candidate for such SVG rendering (I've probably deleted an old naive SVG -> GEGL graph compiler I had lying around, as well as experiments with stroking SVG paths with soft brushes and variable line widths).

GEGL already does various caching of intermediate rendered surfaces and propagation of dirty rectangles in the compositing graph based on graph re-arrangements/property changes. Rendering is at the moment split into spatial regions that are processed sequentially (work is slowly under way to paralellize this processing of rectangular subregions with threads).

The biggest disadvantages I see with doing something primarily vector focused using GEGL at the moment is that GEGL uses sparse tiled buffers, which are not currently supported cairo, thus additional copies are needed for vector rendering. The GEGL model is also currently avoiding any possible in-place compositing of vectors and thus ends up using more copies. The naive approach to convert an SVG document to a GEGL graph also yielded various resampling artifacts as shapes were rasterized prior to transforms being applied, this is an issue that might be possible to work around by making all nodes in the GEGL compositing graph have/be aware of transformation matrices that apply, I have also entertained the idea of passing bezier paths between nodes, allowing nodes in the graph to simply be 2geom "filters" manipulating vector data similar to how raster data is manipulated.

Replacing the full inkscape rendering with GEGL would probably not be a good idea (long term, _I_ probably want to experiment with some such hybrid non-SVG raster/vector authoring UI, with features such as stroking with soft brushes, variable line widths, non SVG 1.2 filters and more, so perhaps it will more sense at some point in the future). Where GEGL and SVG overlap most is SVG 1.2 Filters, it would make sense to use GeglBuffers ability to wrap other in-memory linear buffers (like cairo image surfaces) and do such raster ops using GEGL.

/Øyvind K.

On Fri, Apr 9, 2010 at 12:33 PM, wrote:

On Fri, Apr 09, 2010 at 03:52:03PM +0100, Øyvind Kolås wrote:

2010/4/8 Krzysztof Kosi?ski :

On 4/7/10, Krzysztof Kosi?ski wrote:

Here's my Cairo rendering proposal. I made it public so that all people can comment.

(linking to archived mail instead of full quoting original message) http://article.gmane.org/gmane.comp.graphics.inkscape.devel/33871

To me this looks like a good approach for a cairo based renderer for inkscape, since I maintain GEGL which could possibly considered an alternative I'll post some thoughts on whether GEGLs rendering model could possibly fit into inkscape. (Note, until the last paragraph I list thing that are similar to what is needed, but at the moment probably would be a much worse option than what you have outlined). GEGL deals with many or most of the concerns of an interactive SVG canvas. And at least the long term it should be an eligible candidate for such SVG rendering (I've probably deleted an old naive SVG -> GEGL graph compiler I had lying around, as well as experiments with stroking SVG paths with soft brushes and variable line widths).

GEGL already does various caching of intermediate rendered surfaces and propagation of dirty rectangles in the compositing graph based on graph re-arrangements/property changes. Rendering is at the moment split into spatial regions that are processed sequentially (work is slowly under way to paralellize this processing of rectangular subregions with threads).

A few years ago, Henk Boom did a google summer-of-code project to integrate svg rendering into the Gimp.  His code was placed on hold until enough bogs were fixed in the Gimp to make it prectical to add new features.  If people are starting to look at connecting Inkscape and Gegl, perhaps it's time to dust off his code and have a look at it.

I'm not sure.

GEGL already does more/other vector graphics than the vector layers feature that was added in the GSOC, and in a manner that would seamlessly intergrate with how effect-layers, GEGL based text layers and other composition based enhancements will be done.

As I recall it, the vector layers as implemented in that branch feels like a proof
of concept and the UI integration with the rest of GIMP is rather ad-hoc.

/Øyvind K.