GIMP paths.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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):

<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 " />
.
.
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.
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux