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