Hi all,

I'm experienced GTK+/game developer and 3D artist from Croatia. I want to contribute to development of GIMP.
I encountered one problem which seems as a bug in GIMP. I want to discuss it with you
in order to get bigger picture of the mechanism behind the problem. It is about paths in GIMP.

The problem is manifested when I imported SVG file (the mesh UV Layout generated by Blender 2.53) into GIMP, in order to be able to paint textures by keeping guide-lines with paths.

The paths are not imported/merged properly where SVG image is generated correctly (probably by 'librsvg'?).
The Blender's 'uv.py' exporter script had generated uv's layout as SVG polygons as follows (note that polygon is a quad):

. .
n polys

I thought maybe the problem is that GIMP did not 'understand' how to parse SVG polys. I recoded uv.py to export SVG path as lines but it did not helped. Some suggestions from the net where that converting the line segments into curves will work. I converted them with Inscape but it didn't helped too.

It seemed that there is no easy solution to this problem so I delved into the GIMP code. I found that method 'svg_handler_poly_start' from the 'gimpvectors-import.c' failed to process SVG polygons. The 'points' string is not constructed and 'parse_path_data' method will never be executed. There is a really strange code to parse SVG polygon/polyline which I doubt that is correct.

I recoded the method, where I generate svg lines for each poly as follows (refer to previous polygon):

/// It is blocked in lines for the sake of readability

M67.334,493.895 L67.334,493.895 77.587,494.896 // 1st line M77.587,494.896 L77.587,494.896 78.033,463.871 // 2nd line M78.033,463.871 L78.033,463.871 67.768,463.723 // 3rd line M67.768,463.723 L67.768,463.723 67.334,493.895 // connecting end-start line ( I doubt that 'z' will work in this case )

Note that I simplified the polygon into consecutive 'move to', 'line to' commands, because it seemed for me that 'parse_path_data' cannot process more complex lines with more than 2 points?

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.

Why is GIMP so slow at rendering paths. Is it using 'cairo' or 'gdi' to render paths?

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.

p.s.s. I tested on Ubuntu 10.4 and compiled the actual GIMP code from the repository.

Any help is appreciated.

Kind Regards, Mirza.

Hello,

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/ ).

But not worked for me when whole document is imported. I checked the document and it passed SVG 1.1. validation successfully. I got empty paths imported,
and merged empty path.
I will report this issue as a bug.

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

=)

So this is a cause why I got only outline path visible (after code changes in 'svg_handler_poly_start'). UV layout path is organized as polygonal grid. Generally, if you have a grid of polys and render it XOR-ed, the result is outline, because inner polylines are overlapping. Huh!

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...

It is terribly slow. You don't even need a code profiler to measure a task of painting with path(s) visible and hidden. The units are in seconds. The uv layout path is from a game low poly model, consisted of cca 1000 quads. Some parts are mirrored in uv's so ...it is even less when counting uv vertices.

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.

This means that code for SVG parsing resides in GIMP and in SVG library. When SVG standard upgrades the GIMP SVG parsing code should be updated too. This is error prone solution.
I think that better solution is that 'librsvg' do the parsing job and that GIMP can fetch points from the lib to render. The same points which GIMP now parses from SVG document. These are just plain points, without any stylization which suffice for rendering path. If you consider rendering paths out of OpenGL you will need just points issued via glVertex2** command. The curves needs additional work to interpolate in between points, but final points are also rendered as lines.

Cheers, Mirza.

Using which rsvg function calls exactly?

I checked the 'librsvg' and yes, there is no API exposed to satisfy this. Maybe the 'librsvg' can be subtly redesigned to expose this API? ;-)

> To provide path coordinates flattened > (with all transformations applied) it would have to compute the > transformations itself. So it is not obviously clear, that librsvg *has*

> the data readily available for the use in the GIMP.

It can provide transformation matrix which keeps rotation, translation and scale
in a 4x3 matrix. Or unit matrix if there is no transformations (i.e. in case of Blender's SVG file).
The matrix is then pushed on the stack (cairo, OpenGL) before issuing commands to draw with points.
It is better to do *computation* on GPU side. These things are standardized.

I don't see a good reason to abandon our own parser. If it has problem we need an isolated testcase of a compact, validated SVG that results in bogus paths. Then we can track this down.

I'm afraid that path rendering in GIMP requires a major change. Why not take this step further and make it more flexible and easier to maintain for future development?

Cheers, Mirza.

> Can you please open a bug-report and attach the most simple test case > that you can come up with? We need a small .svg file that illustrates > the problem. I am pretty sure that the problem can easily be fixed then.

Here it is: https://bugzilla.gnome.org/show_bug.cgi?id=629318

Mirza

The grammar parsed by GeglPath is dynamically extendable to also incorporate for instance spiro curves http://libspiro.sourceforge.net/ or other non bezier curves.

I'm looking forward to see it in action.

Mirza

Fixed in GIT. We miscounted the numbers in the "points" string when it had additional whitespace at the end, resulting in a rejection of the data, since an uneven count means invalid data.

Thank you Simon. That was fast.
I tested it, it works.
But, there is another problem with not displaying correctly the paths.

I opened ticked concerning this issue: https://bugzilla.gnome.org/show_bug.cgi?id=629340

I do not expect to be solved as fast as parsing problem (it is XOR problem which I described previously).

Mirza