2010/4/8 Krzysztof Kosiński tweenk...@gmail.com:
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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gegl-developer
