Hello, On Thu, Sep 9, 2010 at 1:13 PM, Mirza Husadzic <mirza.husadzic@xxxxxxxxx> 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 librsvg... > 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. ~LightningIsMyName _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
