On Thu, Sep 9, 2010 at 1:13 PM, Mirza Husadzic <mirza.husad...@gmail.com> wrote:
\> The paths are not imported/merged properly where SVG image is generated
> correctly (probably by 'librsvg'?).
GIMP imports path itself using it's own functions - the reason is that
it can only handle bezier/polygonal strokes (so other elements are
converted to bezier/poloygons). Pretty sure that it's not related to

> The Blender's 'uv.py' exporter script had generated uv's layout as SVG
> polygons as follows (note that polygon is a quad):
> <polygon fill="rgb(204, 204, 204)" fill-opacity="0.5" stroke="black"
> stroke-width="1px"
>   points="67.334,493.895 77.587,494.896 78.033,463.871 67.768,463.723 " />
This was imported perfectly for me, if it still fails to you, maybe
you should filla bug report (Try validation your svg first using the
svg validator - http://validator.w3.org/ ).

> As a result, I got more of the paths lines imported and merged into GIMP,
> but there is a strange drawback.
> The path is not so big, i.e. (few hundred points) but the GIMP is really
> slow at redrawing path (i.e. when painting with brush).
> I also found that if you copy the same path and show them both, nothing is
> displayed? Maybe this is a cause of that all paths are not
> displayed because some of them are overlapping, as the polygons are uv's and
> they overlaps.
GIMP renders path in XOR painting mode for the sake of visibility (XOR
mode is usually easily visible on most possible backgrounds). As a
result, when drawing two paths one above the other, you won't see any
of them since "pixel XOR path XOR path = pixel".
Getting rid of XOR drawing and find something better is on the todo list =)

> Why is GIMP so slow at rendering paths.
> Is it using 'cairo' or 'gdi' to render paths?
GIMP uses gdk for drawing (as far as I remember) indeed, but I have no
idea about the preformance issues. I do know that drawing paths is
indeed a bit slow, but I have no numbers of what should/shouldn't be
normal... Don't forget that blender uses OpenGL for it's drawing, and
this is obviously faster than software only solutions... This should
be targeted again possibly when the canvas drawing will be ported to
cairo (on the todo list for 2.8).

> p.s. I think that SVG parsing should be done by 'librsvg', which should then
> expose even basic API to get only points of basic primitives, such
> as lines, polys, curves etc. In such case GIMP will be concentrated only to
> render them as path into its context.
GIMP is not meant for vector graphics, and therefore I believe that
importing paths as is from svg is enough. Furthermore, since librsvg
is a hard dependancy of GIMP, any plugin can link against librsvg and
know that it will be available. If you believe differently, you are
more than welcome to describe this idea in more detail with some
user-cases (and hopefully with a patch =]) so that it will be
considered again.

Gimp-developer mailing list

Reply via email to