Re: [Gimp-developer] GIMP paths - optimization & tricks
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 > > ___ 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
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 ___ 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
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 > > ___ 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
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 ___ 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 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. > > > > -- > --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 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. ___ 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).
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. -- --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).
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 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 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).
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 > > > ___ > 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).
On 09/13/10 05:47, saulgo...@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 ___ 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).
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). ___ 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
[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.
> 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
Re: [Gimp-developer] GIMP paths.
Mirza Husadzic (mirza.husad...@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 -- si...@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
Re: [Gimp-developer] GIMP paths.
> 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
Re: [Gimp-developer] GIMP paths.
> 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
Re: [Gimp-developer] GIMP paths.
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
Re: [Gimp-developer] GIMP paths.
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
Re: [Gimp-developer] GIMP paths.
> 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
Re: [Gimp-developer] GIMP paths.
Mirza Husadzic (mirza.husad...@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 -- si...@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
Re: [Gimp-developer] GIMP paths.
> 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
Re: [Gimp-developer] GIMP paths.
Mirza Husadzic (mirza.husad...@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 -- si...@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
Re: [Gimp-developer] GIMP paths.
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
Re: [Gimp-developer] GIMP paths.
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
Re: [Gimp-developer] GIMP paths.
> 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
[Gimp-developer] GIMP paths.
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
