Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
On 09/13/10 05:47, saulgo...@flashingtwelve.brickfilms.com wrote: Quoting Mirza Husadzicmirza.husad...@gmail.com: 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
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.husad...@gmail.com 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
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 lc277...@students.mimuw.edu. pl 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 mirza.husad...@gmail.com 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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
2010/9/13 Mirza mirza.husad...@gmail.com: 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. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
On Mon, Sep 13, 2010 at 11:05 AM, yahvuu yah...@gmail.com 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
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 alexiade...@gmail.com wrote: 2010/9/13 Mirza mirza.husad...@gmail.com: 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. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP paths - optimization tricks (getting Blender's 2.53 UV layout as path into GIMP).
Am Sonntag, 12. September 2010 schrub Mirza Husadzic: [...] 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. I haven't looked into your patch nor do I know how GIMP actually draws the paths. So if I'm writing nonsense – just ignore me. ;-) As I understand the previous mails the problem is that each path is painted using XOR so an even number of paths over a single pixel will be invisible. What about not drawing on the canvas using XOR but maintaining an extra 1-bit- buffer on which the paths are painted and which in the end is XORed to the image? I don't know if that's too much overhead or if it doesn't make any sense at all. It just came to my mind … Cheers, Mirza. Tobias signature.asc Description: This is a digitally signed message part. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
