Sent: 2010-09-09 12:13:52 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

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.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-09 15:36:51 UTC (over 1 year ago)

From: Rob Antonishen

GIMP paths.

permalink

> Why is GIMP so slow at rendering paths?

I noticed that just last week. I was trying to use a path a a guide
to paint and gimp was virtually unusable with the path displayed.

This was on XP and 2.6.10

I worked around the issue by stroking the path on a new layer that I
used as a guide.

-Rob A>

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-09 15:52:33 UTC (over 1 year ago)

From: LightningIsMyName

GIMP paths.

permalink

Hello,

On Thu, Sep 9, 2010 at 1:13 PM, Mirza Husadzic 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):
>
> 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@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-09 22:34:37 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

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.

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-09 22:47:30 UTC (over 1 year ago)

From: Simon Budig

GIMP paths.

permalink

Mirza Husadzic (mirza.husadzic@gmail.com) wrote:
> I think that better solution is that 'librsvg' do the parsing job and that
> GIMP can fetch points from the lib to render.

Using which rsvg function calls exactly?

Bye,
Simon

--
simon@budig.de http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-09 23:39:04 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

> 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? ;-)

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-10 00:13:52 UTC (over 1 year ago)

From: Simon Budig

GIMP paths.

permalink

Mirza Husadzic (mirza.husadzic@gmail.com) wrote:
> > 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? ;-)

I did not look at the librsvg internals, but interpreting svg data in a
way that results in a bitmap image is something very different from
preparing SVG data for easy consumption by an application. Just as an
example: Librsvg could just offload all the transformation stuff to
cairo for rendering the image. 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.

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

Bye,
Simon

--
simon@budig.de http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-10 08:57:52 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-10 17:01:53 UTC (over 1 year ago)

From: Øyvind Kolås

GIMP paths.

permalink

On Fri, Sep 10, 2010 at 7:57 AM, Mirza Husadzic
wrote:
> 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?

Depending in any way on librsvg would in my opinion not be a move in
the right direction, the next generation rendering infrastructure of
GIMP called GEGL has it's own path class that allows specifying paths
beyond what SVG deals with (though it probably does not deal with some
of the corner cases for terse condensed path representations in SVGs).
http://git.gnome.org/browse/gegl/tree/gegl/property-types/gegl-path.c

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

/Øyvind K.

--
«The future is already here. It's just not very evenly distributed»
                                                 -- William Gibson
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-10 19:37:28 UTC (over 1 year ago)

From: Sven Neumann

GIMP paths.

permalink

On Thu, 2010-09-09 at 12:13 +0200, Mirza Husadzic wrote:

> 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):
>
> stroke-width="1px"
> points="67.334,493.895 77.587,494.896 78.033,463.871 67.768,463.723
> " />

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.

Sven

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-10 22:29:25 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

> 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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-10 22:39:26 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

> 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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-11 02:02:19 UTC (over 1 year ago)

From: Simon Budig

GIMP paths.

permalink

Mirza Husadzic (mirza.husadzic@gmail.com) wrote:
> > 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

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.

Bye,
Simon

--
simon@budig.de http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Sent: 2010-09-11 10:04:13 UTC (over 1 year ago)

From: Mirza Husadzic

GIMP paths.

permalink

> 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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer