- Inkscape Devel - Inkscape Mailman

Boost for win32
by Bob Jamison 18 Aug '07

18 Aug '07

Hi all, I built Boost with Mingw last night, to help the guys with their new additions to Inkscape. Here it is: http://inkscape.modevia.com/win32libs/boost_1_34_1-mingw411.7z As you can see, it is enormous (28MB). Do we really need Boost, and is it worth doubling the size of the lib bundle? bob

4 6

What to write to font-specification
by Gail Banaszkiewicz 16 Aug '07

16 Aug '07

So as some of you already know, we will be storing more complete font information in the style string so that Inkscape can (eventually) do more than what CSS can represent. However. we need to carefully choose exactly what this information will be. It was suggested previously that we use the system font name, which I was going to use pango to retrieve (http://www.gtk.org/api/2.6/pango/pango-Fonts.html#pango-font-description-to…). However, this function produces almost the same answer as pango_font_description_to_string(), so it's probably just as easy to use that function. I believe this could be reasonable if we trust that pango will not change how this is written (because if they do, we have to make a font-specification-v2 or something). There is another disadvantage: Pango doesn't support anything that CSS doesn't. For quite a long time I thought I could get around this because when pango finds fonts on the system, I was able to print out the information about even the non-CSS styles. Unfortunately, we are currently very dependent on the PangoFontDescription structure, and once this structure is obtained from this point on, we lose all non-CSS information. There are two things I would like to look into in the future: first, whether we can around this super-dependence on that structure and could use instead somehow the PangoFontFace structure that seems to contain all needed information; and second, perhaps contributing to pango and/or finding out why they don't have more general font support. Anyway, so the reason for this email is to get some of your ideas on what you think we should put into font-specification. Tell me why too! Thanks, Gail

2 2

bug #1774456: snapping
by Felipe Sanches 16 Aug '07

16 Aug '07

I have compiled revisions 15637 and 15638. Revision 15638 introduced the bug #1774456 Log: "Rearrange snapping preferences, put distinction between paths and nodes back in, and a bit of refactoring" Juca

2 1

LPE committed to trunk!
by unknown＠example.com 15 Aug '07

15 Aug '07

Hi all, I just committed LPE to trunk. I have chosen to put the necessary 2geom files into inkscape svn, and build them together with inkscape. Windows building works fine, and Linux aswell! :) One must download Boost, but it seems only 3 files are needed. concept_check.hpp, format.hpp and optional/optional.hpp. I think this means only the boost base is needed and the "optional" package. No harm downloading all though... http://www.boost.org/ (please note I did not test this, I downloaded the complete boost package) I updated the LPE build info on the wiki, if you have trouble building: http://wiki.inkscape.org/wiki/index.php/LivePathEffects#BUILDING_THE_BRANCH Really hope I did not break building! Cheers, Johan Note 1.: There are some warnings on Linux, because of duplicate entries in the makefile. I do not know why 2geom is put twice in the makefile. Note 2.: I had to exclude extension/internal/bitmap/*.* in build.xml to get Inkscape built (trunk rev 15177, so without LPE changes)

2 2

bounding box
by Felipe Sanches 15 Aug '07

15 Aug '07

hi! I have a doubt. How do I read the bounding box coordinates from within a NR::FilterPrimitive ? (I think that) I need this to implement the feImage filter primitive Juca

3 3

Re: [Inkscape-devel] Multithreading (with TBB)
by Dennis J Lin 15 Aug '07

15 Aug '07

Salutations! >However, as for diagonal scrolling, I had an impression that the >existing code in sp_canvas_paint_rect already addresses this: [snip] >So, can you please provide more details on your approach? Actually, the problem is earlier. A diagonal expose event dirties a L-shaped region of tiles. Then, in 2036 static int 2037 paint (SPCanvas *canvas) 2038 { we have 2060 if ( canvas->tiles[tile_index] ) { // if this tile is dirtied (nonzero) 2061 dirty = true; 2062 // make (pl..pr)x(pt..pb) the minimal rect covering all dirtied tiles 2063 if ( i < pl ) pl = i; 2064 if ( i+1 > pr ) pr = i+1; 2065 if ( j < pt ) pt = j; 2066 if ( j+1 > pb ) pb = j+1; 2067 } which forces a full-screen redraw. My solution was to use a Gdk::Region to construct a better region for redraw. I was also thinking of getting rid of canvas->redraw_aborted altogether, and just not "cleaning" the dirty tiles until the redraw actually happens. I think that this way, we will be prepared for simultaneous dirty/redraw events. (My work so far doesn't do that yet -- it does the rendering in parallel, but blocks the main thread.) Alternatively, we can upgrade (and probably rename) the canvas->redraw_aborted to a Gdk::Region (or a GdkRegion -- what's preferred?) and forget about the tiles. We will probably want to divide by TILE_SIZE to avoid redrawing 1-pixel areas. >> Is the intent to move everything to Cario in the near future? > >Yes. Certainly. However, as planned now, the move to cairo will not >get rid of nr-arena-shape. We plan to just remove the rendering calls >to livarot methods and reduce the lots of extra buffers that are now >created and then composed. Instead we'll just use cairo calls to draw >shapes in a single buffer. See the outline mode which is now drawn >entirely by cairo - the regular mode will be similar except a lot more >code will be needed to translate gradients, patterns, etc. to cairo >format. Ok. I was wondering if there was a going to be a massive rewrite to C++ or something. >I don't think they realistically will be rewritten in the near future. >At least sp-canvas seems to be more or less adequate for our needs, >with or without cairo. Yeah, the odd thing is that the sp-canvas seems to hold only 3 items -- one is the canvas-arena with everything else and there are two SPCtrlRects. This seems like a bit of duplication of effort. (This doesn't bother me right now, but we should probably merge the two sometime before/during when we allow scene to change while we are rendering.) >> Finally, I would like to gauge the interest in this work. What are your sentiments on multithreading in general, and in using TBB to do in particular? > >We know we're in a rather bad shape with regard to multithreading :) >But there's certainly a lot of interest for exploring what can still >be done to improve the situation. Cool, I'll definitely package up everything I've done by Friday, and we'll see how busy school gets ;-) Dennis Lin

3 2

Re: [Inkscape-devel] Multithreading (with TBB)
by Dennis J Lin 14 Aug '07

14 Aug '07

Salutations! (Sorry if the threading is wrong, I'm working with a webmail client right now.) >I think the current status is that we're not very thread safe :) I >guess my concern is that probably the first step for us isn't >implementing TBB. The first step is getting everything cleaned up so >that implementing TBB is a reasonable next step. I agree with you, but I wanted to have something to show, so I decided to tackle the rendering portion (which can take several seconds for a heavily filtered image like car.svgz.) So right now, I have a version that can render to different regions of the screen at the same time (there are locks protecting nr-arena-shape, so there is potential contention.) > >As far as TBB itself goes, is it in any distros? How does it work with >the whole Glib main loop? Perhaps implementing TBB in GTKmm is a good >first step? It might be interesting to incorporate TBB with libsigc++, so that signals can be processed in parallel. Actually, that was what I was thinking about doing when I happened upon Inkscape. >It seems to be one of the trickiest parts, in that we would like to have >the GTK+ GUI responsive while processing is occurring as it would >probably be the biggest perceived gain for users -- but is likely the >most complex part. I think this ties directly into the issues the guys >and Grinnel are seeing. Yeah, I think that eventually I'm going to run into similar issues. For right now, however, I'm just reading the tree (during the idle timer event), so I don't have to worry about updates. As for the future, I think I can have aborted redraws working today or tomorrow (so that the system isn't *less* responsive). Maybe I can get it to the point that we can scroll and redraw at the same time before Friday. Anything fancier, however, is going to require a bunch of careful refactoring... Dennis Lin

1 0

Multithreading (with TBB)
by Dennis J Lin 14 Aug '07

14 Aug '07

Salutations! My name is Dennis Lin, and (until Friday) I'm an intern at Intel. As you may have heard, Intel has released a GPL version of Thread Building Blocks (http://osstbb.intel.com/). In an attempt to gain greater adoption, they have asked me to look into using it to thread existing open-source applications. I've played with the Inkscape source for the last couple of weeks, and I should have some patches soon. I'll try to put out a patch later today to avoid redrawing the entire screen when scrolling diagonally. (This should be independent of scrolling). Where do you prefer your patches? I also have some questions as to how I should proceed. I have found (the hard way) that nr-arena-shape is very *not* threadsafe. However, the Cairo version seems to be a lot better. Is the intent to move everything to Cario in the near future? (I probably don't have enough time remaining to do the conversion, but I might be able to get started, and I can continue on my "free time" after school starts again.) More generally, I have noticed that the sp-canvas and nr-arena-item seem to be scheduled for a rewrite. I have been trying to keep my changes relatively unintrusive, but I was wondering what direction I should be trying to nudge things. Finally, I would like to gauge the interest in this work. What are your sentiments on multithreading in general, and in using TBB to do in particular? Thank you for your time, Dennis Lin

4 3

build failure - paramcolor
by jiho 14 Aug '07

14 Aug '07

I am getting this with latest SVN: depbase=`echo extension/paramcolor.o | sed 's|[^/]*$|.deps/&|;s|\.o $||'`;\ g++ -DHAVE_CONFIG_H -I. -I.. -I/opt/local/include/freetype2 -I/opt/ local/include -D_REENTRANT -DORBIT2=1 -I/opt/local/include/gnome- vfs-2.0 -I/opt/local/lib/gnome-vfs-2.0/include -I/opt/local/include/ gconf/2 -I/opt/local/include/orbit-2.0 -I/opt/local/include/glib-2.0 - I/opt/local/lib/glib-2.0/include -I/opt/local/include -DXTHREADS - I/opt/local/include -I/opt/local/include/freetype2 -I/usr/X11R6/ include -DPNG_NO_MMX_CODE -DXTHREADS -I/opt/local/include/gtk-unix- print-2.0 -I/opt/local/include/gtk-2.0 -I/opt/local/include/atk-1.0 - I/opt/local/include/cairo -I/opt/local/lib/gtk-2.0/include -I/opt/ local/include/pango-1.0 -I/opt/local/include/glib-2.0 -I/opt/local/ lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/ freetype2 -I/opt/local/include/libpng12 -I/usr/X11R6/include - DPOTRACE=\"potrace\" -DPNG_NO_MMX_CODE -DXTHREADS -D_REENTRANT -I/opt/ local/include/gdkmm-2.4 -I/opt/local/lib/gdkmm-2.4/include -I/opt/ local/include/glibmm-2.4 -I/opt/local/lib/glibmm-2.4/include -I/opt/ local/include/pangomm-1.4 -I/opt/local/include/gtk-2.0 -I/opt/local/ lib/gtk-2.0/include -I/opt/local/include/cairomm-1.0 -I/opt/local/ include/sigc++-2.0 -I/opt/local/lib/sigc++-2.0/include -I/opt/local/ include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/ include -I/opt/local/include/pango-1.0 -I/opt/local/include/cairo -I/ opt/local/include/freetype2 -I/opt/local/include/libpng12 -I/usr/ X11R6/include -I/opt/local/include/gtkmm-2.4 -I/opt/local/lib/ gtkmm-2.4/include -I/opt/local/include/atkmm-1.6 -I/opt/local/include/ atk-1.0 -I/opt/local/include/libxml2 -I../cxxtest -I/opt/local/ include -Wall -Wformat-security -W -Wpointer-arith -Wcast-align - Wsign-compare -Woverloaded-virtual -Wswitch -D_FORTIFY_SOURCE=2 -Wno- unused-parameter -O3 -Wall -MT extension/paramcolor.o -MD -MP -MF $depbase.Tpo -c -o extension/paramcolor.o extension/paramcolor.cpp &&\ mv -f $depbase.Tpo $depbase.Po extension/paramcolor.h:26: warning: unused parameter ‘doc’ extension/paramcolor.h:26: warning: unused parameter ‘node’ extension/paramcolor.cpp:43: warning: unused parameter ‘doc’ extension/paramcolor.cpp:43: warning: unused parameter ‘node’ >>>>>>>>>>>>>>> extension/paramcolor.cpp: In constructor ‘Inkscape::Extension::ParamColor::ParamColor(const gchar*, const gchar*, const gchar*, Inkscape::Extension::Parameter::_scope_t, Inkscape::Extension::Extension*, Inkscape::XML::Node*)’: extension/paramcolor.cpp:76: error: ‘strndup’ was not declared in this scope extension/paramcolor.cpp: At global scope: >>>>>>>>>>>>>>> extension/paramcolor.cpp:109: warning: unused parameter ‘doc’ extension/paramcolor.cpp:109: warning: unused parameter ‘node’ extension/paramcolor.cpp: In function ‘void Inkscape::Extension::sp_color_param_changed(SPColorSelector*, GObject*)’: extension/paramcolor.cpp:139: warning: unused variable ‘rgba’ make[2]: *** [extension/paramcolor.o] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 JiHO --- http://jo.irisson.free.fr/

2 4

Tweak tool on straight lines: "feature" or "bug"
by jiho 14 Aug '07

14 Aug '07

Hello all (and bulia in particular), I just discovered that the Tweak tool as no effect on straight lines (on the middle of straight lines to be exact, because it can move the end nodes). Even when there are nodes in the middle, passing the tweak tool avec a straight line does not deform it. I would expect this: | | | | | | | to become more or less this: | | \ \ | / / | I after passing the Tweak tool over it. Is it a feature? a bug? Cheers, JiHO --- http://jo.irisson.free.fr/

2 2