[Inkscape-devel] Cairo rendering proposal

2010/4/8 Krzysztof Kosiński <tweenk.pl@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.

On Fri, Apr 09, 2010 at 03:52:03PM +0100, Øyvind Kolås wrote:
> 2010/4/8 Krzysztof Kosiński <tweenk.pl@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).

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.

-- hendrik

On Fri, Apr 9, 2010 at 12:33 PM, <hendrik@topoi.pooq.com> wrote:
> On Fri, Apr 09, 2010 at 03:52:03PM +0100, Øyvind Kolås wrote:
>> 2010/4/8 Krzysztof Kosiński <tweenk.pl@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).
>
> 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.