Re: [Gimp-developer] (no subject) plus dockables
On 09/01/2010 12:45 PM, yahvuu wrote: O Peter, Where Art Thou? This is getting nasty quickly. On 28.08.2010 20:13, Sven Neumann wrote: On Fri, 2010-08-27 at 07:32 +0200, Martin Nordholts wrote: If I want a colour , I should find it on the colour menu . If I want to select layers I should fine the necessary interface elements on the layer menu. Sounds reasonable. We could duplicate the menu items from the Dockables menu that raise/create those dialogs in the places where they belong. So we would have Layers dialog in the Image/Layers menu and the like. That's as simple as editing the XML files in the menus sub-directory. Perhaps someone wants to come up with a patch... I don't think we should duplicate any menu items. Having things in two places tends to cause unnecessary confusion. A user will have to answer questions like Why is this menu item in two places? Is it the same menu item? Does it do the same thing? Which one should I use now? Having just one place to do things avoids such ambiguity and mental friction. We do that for a few menu items already and I don't think it has ever caused any problems. Some examples are (and there are many more): Edit-Undo History View-Navigation Window Select-Selection Editor Colors-Info-Histogram Actually I think it's just an oversight that the Layers dialog is missing from the Layers menu. IMO all dialogs should be accessible from the menus where they belong to functionally. The Dockables menu is just a place to list all the available dialogs. It should be secondary. Another thing to note is that the 'Add Tab' entry from the dockable context menu provides a list of available dockables as well. I think i can explain why this additional option for dockable creation does not create much mental friction: When i'm browsing the 'Layer' menu, i'm thinking of what can be done with layers. Here is the place to discover the layers dialog -- i can find it here even if i do not have prior knowledge that a layers dialog exists at all. On the other hand, when adding a tab to an existing docbook using the 'Add Tab' menu, i'm configuring my workspace to better suit the task at hand -- that's a different kind of process than browsing for layer functionality. Windows-Dockable Dialogs is literally in the middle of these two choices. Perhaps we can weasel out by proclaiming that this isn't a 'menu' but just a list of available dialogs and thus no decision has to be made about which menu to use... That is, paraphrasing what Sven said. Your explanation makes sense, my reasoning was broken. I will try fix this for 2.8 (unless, of course, someone does it before me) / Martin -- My GIMP Blog: http://www.chromecode.com/ Automatic tab style and removed tab title bar ___ 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): polygon fill=rgb(204, 204, 204) fill-opacity=0.5 stroke=black stroke-width=1px points=67.334,493.895 77.587,494.896 78.033,463.871 67.768,463.723 / . . 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
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
Re: [Gimp-developer] GIMP paths.
Hello, On Thu, Sep 9, 2010 at 1:13 PM, Mirza Husadzic mirza.husad...@gmail.com 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): polygon fill=rgb(204, 204, 204) fill-opacity=0.5 stroke=black 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.
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.
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.
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: 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
