2010/4/8 Krzysztof Kosiński <tweenk.pl@xxxxxxxxx>: >> 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. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://gegl.org/ _______________________________________________ Gegl-developer mailing list Gegl-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
