Quoting Mirza Husadzic :

Hi all,

I came up with solution to import and merge Blender's SVG file as path into GIMP.
:
:
I was quite depressed yesterday, but in the middle of night I got an idea :-)
"If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!?"
If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. :
:
I would like to hear you opinions.

Why not implement your removal of overlapping path segments as a separate plug-in which can be executed on any paths, not just imported ones? Doing this would eliminate the import interface offering an option which addresses a hardware/graphics "preview" limitation which many users would not, and would not care to, understand (and may disappear in the future).

On 09/13/10 05:47, saulgoode@flashingtwelve.brickfilms.com wrote:

Quoting Mirza Husadzic:

Hi all,

I came up with solution to import and merge Blender's SVG file as path into GIMP.
:
:
I was quite depressed yesterday, but in the middle of night I got an idea :-)
"If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!?"
If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP. :
:
I would like to hear you opinions.

Why not implement your removal of overlapping path segments as a separate plug-in which can be executed on any paths, not just imported ones? Doing this would eliminate the import interface offering an option which addresses a hardware/graphics "preview" limitation which many users would not, and would not care to, understand (and may disappear in the future).

hi,

a quick look at the bug from 2001 suggests this is the underlying issue that affects more than just the svg problem. XOR is a fundamentally flawed way of dealing with overlapping elements.

This bug has been repeatedly kicked into the long grass since it was opened. Presumably the best solution would be to deal with the root cause: xor.

Removing duplicates would be a reasonable workaround for the mesh problem. Does it have a wider application?

/gg

Hello,

The same as Tobias, I'm not in the topic of paths, so maybe I'm wrong, but you wrote that you add each path (x1, x2, y1, y2) to the hash table and look for duplicates. And what if only a part of a path overlaps? Consider paths: (2,4,2,4) and (1,3,1,3) - then the overlapping fragment will be a path (1,2,1,2), won't it?

?ukasz Czerwi?ski

2010/9/12 Mirza Husadzic

Hi all,

I came up with solution to import and merge Blender's SVG file as path into GIMP.
This is just quick and dirty solution which I hacked this afternoon. But it works very well.
I opened bug report yesterday concerning GIMP's invalid path-line drawing ( https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that
things will change really slow:-).
I was quite depressed yesterday, but in the middle of night I got an idea :-)
"If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!?"
If duplicates are removed, then XOR drawing will not affect path. Yupiee. As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization for poor gdk-powered line drawing in GIMP.

Here is a SVG file for testing: http://www.qsoftz.com/mirza/wp-content/data/gekkoman_unwrapp.svg Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop: http://www.qsoftz.com/mirza/wp-content/data/Screenshot.png Here is a patch:
http://www.qsoftz.com/mirza/wp-content/data/0001-cleared-duplicate-lines.patch

btw. I used slower variant 'g_hash_table_find' instead of 'g_hash_table_lookup'. I know that this is a flaw. I will try to fix it.

And yes, rendering of this kind of optimized path is much better than without optimization.
I'm able to work and paint (realtime) over this path. I'm very happy! :-)

About patch:

The code affects processing only if paths are merged while importing (checked "Merge imported path").
I'm not sure that I placed code at right place. I'm not sure how it will affect importing of other entities from SVG file (curves, ellipses etc.).

But, I'm pretty sure that this is a good way in direction of merging paths.

It is useless if they are not flattened into only one path, without duplicated points.

The algorithm:

As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke).
That's it.

This method can be applied even if paths are merged from GUI. I will further test this approach
with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too.
But, I'm not sure about this. I didn't tested it.

I would like to hear you opinions.

Cheers, Mirza.

www.qsoftz.com
www.qsoftz.com/mirza

Then test should be extended to look for collinear lines.
But principle should be the same, which means that collinear lines will be removed from flattened path.

Mirza.

On 13. ruj. 2010., at 10:42, ?ukasz Czerwi?ski wrote:

Hello,

The same as Tobias, I'm not in the topic of paths, so maybe I'm wrong, but you wrote that you add each path (x1, x2, y1, y2) to the hash table and look for duplicates. And what if only a part of a path overlaps? Consider paths: (2,4,2,4) and (1,3,1,3) - then the overlapping fragment will be a path (1,2,1,2), won't it?

?ukasz Czerwi?ski

2010/9/12 Mirza Husadzic Hi all,

I came up with solution to import and merge Blender's SVG file as path into GIMP.
This is just quick and dirty solution which I hacked this afternoon. But it works very well.
I opened bug report yesterday concerning GIMP's invalid path-line drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that
things will change really slow:-).
I was quite depressed yesterday, but in the middle of night I got an idea :-)
"If GIMP cannot draw overlapped lines, then why should draw them *overlapped* after all!?"
If duplicates are removed, then XOR drawing will not affect path. Yupiee.
As a side effect, there will be approx. half of lines less to draw (in case of connected polygons a.k.a mesh) so this is a very good optimization
for poor gdk-powered line drawing in GIMP.

Here is a SVG file for testing: http://www.qsoftz.com/mirza/wp-content/data/gekkoman_unwrapp.svg Here is a screenshot of GIMP with paths on my lovely Ubuntu desktop: http://www.qsoftz.com/mirza/wp-content/data/Screenshot.png Here is a patch: http://www.qsoftz.com/mirza/wp-content/data/0001-cleared-duplicate-lines.patch

btw. I used slower variant 'g_hash_table_find' instead of 'g_hash_table_lookup'. I know that this is a flaw. I will try to fix it.

And yes, rendering of this kind of optimized path is much better than without optimization.
I'm able to work and paint (realtime) over this path. I'm very happy! :-)

About patch:

The code affects processing only if paths are merged while importing (checked "Merge imported path").
I'm not sure that I placed code at right place. I'm not sure how it will affect importing of other entities from SVG file (curves, ellipses etc.).

But, I'm pretty sure that this is a good way in direction of merging paths.
It is useless if they are not flattened into only one path, without duplicated points.

The algorithm:

As strokes are processed the key for each line in stroke (x1,x2,y1,y2) is constructed and pushed into hash table. If key is uniuqe then line in stroke is valid. If key is duplicated, then line is rejected and current stroke ends (begin of a new stroke).
That's it.

This method can be applied even if paths are merged from GUI. I will further test this approach
with other shapes from SVG (cubic bezier, ellipse etc). If they are flattened on lines, at this stage, maybe this may work with them too.
But, I'm not sure about this. I didn't tested it.

I would like to hear you opinions.

Cheers, Mirza.

www.qsoftz.com
www.qsoftz.com/mirza

2010/9/13 Mirza :

Then test should be extended to look for collinear lines.
But principle should be the same, which means that collinear lines will be removed from flattened path.
Mirza.

No. Just... no. XOR needs to die. Badly.

On 13.09.2010 11:47, Alexia Death wrote:

No. Just... no. XOR needs to die. Badly.

just curious: what coloring options exist to enshure sufficient background contrast when drawing non-XORed/anti-aliased?

thx, yahvuu

On Mon, Sep 13, 2010 at 11:05 AM, yahvuu wrote:

On 13.09.2010 11:47, Alexia Death wrote:

No. Just... no. XOR needs to die. Badly.

just curious: what coloring options exist to enshure sufficient background contrast when drawing non-XORed/anti-aliased?

One good way of doing it is drawing two strokes with slightly different width and contrasting (perhaps transparent) contrasting colors you will achieve sufficient contrast. An old example of such rendering using cairo can be seen here: http://pippin.gimp.org/curve.jpg

/Øyvind K.

There is no doubt about XOR drawing. It should be fixed asap so GIMP development can continue more clearly. But, if you merge some complex path and there is no way to unmerge, it is useless to keep collinear lines.
This is just optimization from which users can benefit to import more complex shapes. From which path selection can be traced etc.

I dont know which are goals of GIMP, this is just my point of view about programming in general. If there is a demand to optimize bottlenecks I will do it. Drawing half of something (at visible area) is pretty good optimization.

Mirza.

On 13. ruj. 2010., at 11:47, Alexia Death wrote:

2010/9/13 Mirza :

Then test should be extended to look for collinear lines.
But principle should be the same, which means that collinear lines will be
removed from flattened path.
Mirza.

No. Just... no. XOR needs to die. Badly.

On Sun, 2010-09-12 at 23:25 +0200, Mirza Husadzic wrote:

Hi all,

I came up with solution to import and merge Blender's SVG file as path into GIMP.
This is just quick and dirty solution which I hacked this afternoon. But it works very well.
I opened bug report yesterday concerning GIMP's invalid path-line drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that
things will change really slow:-).

Actually I have fixed the paths drawing problem Friday evening and the problem is solved in my tree. Just needs a little more work to finish it. So please stop wasting your time with work-arounds.

Sven

Thank you Sven.
Actually I didn't wasted my time more on this so far, beacause I'm able to continue my work with painting textures where I jammed last week.
I know that I just scratched the surface in this short time and in order to do more solid solution I need to learn more and to look for your help.

This is a very good news that it would be solved at git head, and finally realesed with new version of GIMP. I'm sure that many 3D artists will be happy with that fix. This is for sure one of reasons why some of them looked for alternative over GIMP. And this is a reason why I'm such a pain in the ass about this ;-) Because, I want to improve GIMP. And after all I'm doing it with your help. Thanks again ;-)

Please consider optimization with merged paths as this is crucial to smooth rendering on current GIMP's architecture.

Cheers, Mirza.

On 13. ruj. 2010., at 20:19, Sven Neumann wrote:

On Sun, 2010-09-12 at 23:25 +0200, Mirza Husadzic wrote:

Hi all,

I came up with solution to import and merge Blender's SVG file as path
into GIMP.
This is just quick and dirty solution which I hacked this afternoon. But it works very well.
I opened bug report yesterday concerning GIMP's invalid path-line drawing (https://bugzilla.gnome.org/show_bug.cgi?id=629340). Then, as Sven marked this ticket as duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=55364 (dating form 2001) I realized that
things will change really slow:-).

Actually I have fixed the paths drawing problem Friday evening and the problem is solved in my tree. Just needs a little more work to finish it. So please stop wasting your time with work-arounds.

Sven

On Mon, 2010-09-13 at 22:19 +0200, Mirza wrote:

Please consider optimization with merged paths as this is crucial to smooth rendering on current GIMP's architecture.

Such "optimizations" don't belong into the core. We already provide the infrastructure for scripts and plug-ins to hook into the Paths dialog where they could provide a menu entry to "Remove overlapping paths".

Sven

Ok good, I will investigate how it can be done within plugin or script.

Unfortunatelly I'm on trip until next Friday, so this will wait some time until I come home.

Cheers, Mirza

On 14. ruj. 2010., at 22:03, Sven Neumann wrote:

On Mon, 2010-09-13 at 22:19 +0200, Mirza wrote:

Please consider optimization with merged paths as this is crucial to smooth rendering on current GIMP's architecture.

Such "optimizations" don't belong into the core. We already provide the
infrastructure for scripts and plug-ins to hook into the Paths dialog where they could provide a menu entry to "Remove overlapping paths".

Sven