August 2014 - Inkscape Devel - Inkscape Mailman

Review LPE Show Handles
by Jabiertxo Arraiza Cenoz 10 Aug '14

10 Aug '14

Hi to all, I lost ask for a reviewer to the new LPE. If anybody want, the code are in: https://code.launchpad.net/~inkscape.dev/inkscape/show_handles Jabier.

1 0

New LPE "Show Handles"
by Jabiertxo Arraiza Cenoz 10 Aug '14

10 Aug '14

A new video for a new LPE, is like show handles extension. I reuse -and improve- some of my simplify LPE to do it by a sugestion of suv. https://www.youtube.com/watch?v=h9ul_PR9XYo

1 0

0.48.5 and libsigc++-2.3.2
by Ken Moffat 08 Aug '14

08 Aug '14

Hi, I do some things at beyond linuxfromscratch ( http://www.linuxfromscratch.org/blfs/view/svn/ ) and have recently started including 0.48.5 in my own builds. We have been using libsigc++-2.3.1 for some time (I guess that whoever added it did not realis it was a development version), so we went with 2.3.2. Unfortunately, that breaks inkscape-0.48.5. The specific change was announced at https://mail.gnome.org/archives/libsigc-list/2014-August/msg00000.html where it mentioned runtime errors for users who added their own visit_each overload. In fact, for 0.48.5 it broke the build, and the relevant message appeared to be : /usr/include/sigc++-2.0/sigc++/visit_each.h:169:64: error: cannot convert ‘const sigc::adaptor_functor<sigc::bound_mem_functor0<void, SPDesktop> >’ to ‘int’ in initialization /usr/include/sigc++-2.0/sigc++/visit_each.h:169:29: warning: unused variable ‘do_visit_each’ [-Wunused-variable] { sigc::visitor<T_functor>::do_visit_each(_A_action, _A_functor); } ^ CXX device-manager.o Makefile:5958: recipe for target 'desktop.o' failed make[2]: *** [desktop.o] Error 1 Dropping back to 2.3.1 fixed it. One of my colleagues created a patch to locally revert that particular change in libsigc++ which also fixed the build. My first question [ at last! ] is: Do you care about people who build 0.48 with libsigc++-2.3-series ? If you do, any ideas how to fix this ? Thanks. ĸen -- Nanny Ogg usually went to bed early. After all, she was an old lady. Sometimes she went to bed as early as 6 a.m.

3 9

Cairo rendering of SVG arcs
by Liam White 08 Aug '14

08 Aug '14

Hi I found out that for certain SVG files, rendering can likely be sped up a lot by directly rendering SVG elliptical arcs with Cairo instead of converting them to cubic Beziers and rendering those. I expanded our current code in experimental to do that, and it... almost works. I'm not quite sure what I'm doing wrong at the moment, hopefully someone can help me with that! The code works well for perfect circles. It does not work well for ellipses, but doesn't seem to have any issues with rotation of ellipses. Any optimization tips would be appreciated, as this code is called extremely often. #line 558 "src/display/cairo-utils.cpp" else if (Geom::EllipticalArc const *a = dynamic_cast<Geom::EllipticalArc const*>(&c)) { Geom::EllipticalArc* tx = static_cast<Geom::EllipticalArc *>(a->transformed(trans)); Geom::Affine xform = tx->unitCircleTransform(); // Normalize the ellipse into a circle Geom::EllipticalArc * ax = static_cast<Geom::EllipticalArc *>(tx->transformed(xform)); bool sweep = /*ax->sweep(), large_arc = */ax->largeArc(); Geom::Point ce = ax->center(); Geom::Point ang(ax->initialAngle().radians(), ax->finalAngle().radians()); // Apply the transformation to the current context cairo_save(cr); cairo_matrix_t cr_trans; xform = xform.inverse() * trans; cairo_matrix_init(&cr_trans, xform[0], xform[1], xform[2], xform[3], xform[4], xform[5]); cairo_transform(cr, &cr_trans); if (!optimize_stroke || tx->boundsFast().intersects(view)) { // Draw the circle if (sweep) { cairo_arc(cr, ce[X], ce[Y], ax->ray(X), ang[0], ang[1]); } else { cairo_arc_negative(cr, ce[X], ce[Y], ax->ray(X), ang[0], ang[1]); } } else { cairo_move_to(cr, ax->finalPoint()[X], ax->finalPoint()[Y]); } cairo_restore(cr); delete tx; delete ax; return; } http://cairographics.org/manual/cairo-Paths.html#cairo-arc

3 2

Re: [Inkscape-devel] Cairo rendering of SVG arcs
by Liam White 07 Aug '14

07 Aug '14

Thanks Krzysz! That fixed it and now CLI rendering of a file with a tremendous amount of arcs seems to be a bit faster: Unpatched trunk: 0m9.161s Patched trunk: 0m7.577s However, something else I might have to investigate is that with my sample file, experimental seems to have suffered a serious performance regression: Unpatched experimental: 0m20.539s Patched experimental: 0m19.482s

1 0

Re: [Inkscape-devel] SVG2 hatch rendering
by Tomasz Boczkowski 07 Aug '14

07 Aug '14

> It doesn't look terrible here... > In particular it'd be good to know if you're using cairo that includes > the downscaling patch added to cairo last week. If not, then please > re-test with a newer snapshot of cairo. I use cairo 1.12.16 distributed with opensuse 13.1. Tomasz On Tue, Aug 5, 2014 at 10:40 PM, Bryce Harrington <b.harrington@...3042...> wrote: > On Tue, Aug 05, 2014 at 01:32:16PM -0700, Josh Andler wrote: > > On Tue, Aug 5, 2014 at 1:12 PM, Tomasz Boczkowski < > penginsbacon@...400...> > > wrote: > > > > > The image illustrating the aliasing problem is: > > > https://www.dropbox.com/s/r1hlmpwuagdq8cj/hatch_rendering_zoom.png > > > > > > > Is that possibly related to cairo or pixman version? It doesn't look > > terrible here... > > https://www.dropbox.com/s/amnq9c8c64thxrk/hatches.png > > In particular it'd be good to know if you're using cairo that includes > the downscaling patch added to cairo last week. If not, then please > re-test with a newer snapshot of cairo. > > Bryce > > > > >

3 4

Recent change to SVG parsing
by Krzysztof Kosiński 07 Aug '14

07 Aug '14

Hello Recently there was a change to SVG parsing in lib2geom, so that arc segments that end less that EPSILON (1e-5) units from where they begin are ignored. However, this threshold is completely arbitrary and there is no way to change it. I think this should either be changed to strict equality, or there should be a way to set this threshold (in Inkscape, it should be dependent on the numeric precision of XML output). Regards, Krzysztof

4 3

Re: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2
by Ruben Van Boxem 06 Aug '14

06 Aug '14

As the previous email was sent only to one person, see below as well :-) I forgot to mention one thing: MSYS2 has a clang that can be used to compile applications. Unfortunately, GCC 4.9.1 header locations aren't yet added to the build, so currently it's not possible to use it. Note that Clang on Windows only works on 32-bit (for now, will change in the future) and with the dw2 C++ exceptions implementation. It uses and links to libgcc and GCC's libstdc++, no libc++ on Windows yet. Ruben From: rubenvb.development@...3139... To: jbc.engelen@...2592... Subject: RE: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2 Date: Wed, 6 Aug 2014 15:22:13 +0200 Hi guys, I'm not replying in-line because, well, the outlook.com web interface doesn't indent the previous message like gmail does. Now I have a reason to stick with gmail :-p On-topic: I understand you like the devlibs setup, but as you say yourselves, setting it up and maintaining it is a pain. My message was just meant as an FYI, for your consideration. I won't prevent you from using the binary packages built by the MSYS2 project and integrating those into your devlibs. But I'd only think it fair you credit the project for their work (I'm actually not involved in its development in any way). I think just copying the libraries from the MSYS2 packages should work. Note that C++ is a bit more ABI sensitive than C, and those packages will need a matching GCC variant. (sjlj-dw2-seh and win32-posix internal GCC threads). C code will also be affected by the internal thread implementation GCC uses. Note this does not affect your code or the generated code whatsoever. Just what GCC (libgcc) uses internally. Huh, I didn't find any 64-bit builds on the download page, if you want them to be picked up, you should place them alongside the 32-bit builds, otherwise people aren't even going to try them ;-) http://inkscape.org/en/download/windows/ or http://sourceforge.net/projects/inkscape/files/inkscape/0.48.5/ Cheers, Ruben Date: Fri, 1 Aug 2014 21:00:58 +0200 From: jbc.engelen@...2592... To: inkscape-devel(a)lists.sourceforge.net; rubenvb.development@...3139... Subject: Re: [Inkscape-devel] Inkscape Windows compile instructions and MinGW-w64/MSYS2 Hi Ruben, On 31-7-2014 16:11, Liam White wrote: The devlibs setup is actually the most simplified way to build Inkscape, because one does not need to download and install MSYS to build it on Windows this way. I agree with Liam. Our current setup for Windows is about as simple as I can imagine (for both 32 and 64 bit). The most difficult thing is setting up Bazaar, which is unrelated to setting up the build environment. Once one can checkout Inkscape's source, the only build setup steps that are required are: bzr checkout devlibs, and downloading and unzipping mingw. There is very little room for improvement here; certainly MSYS2's installation instructions are more 'difficult'. I don't think setting up our build setup is preventing developers on Windows to join the project. That said, there is a cost of our simplicity: someone has to maintain the devlibs. With the hard work of Partha and Liam, we have managed to get devlibs64 up; without them we probably still would not have had 64bit. 64-bit builds are possible because we modified our code to get it built with 64bit! We already have official 64bit builds :) It'd be nice to have another project maintain a "devlibs", effectively what MSYS2 would provide for us, possibly at the cost of some *reduced* simplicity in setting up the build environment (based of of the installation instructions online for MSYS2). Perhaps it is as easy as just copying the binaries/headers into our devlibs though... regards, Johan (Does MSYS2 provide clang binaries that are usable for compiling Inkscape?) On Jul 31, 2014 4:00 AM, "Ruben Van Boxem" <rubenvb.development@...3139...> wrote: Hi everyone, I wanted to explore the possibility of a 64-bit Windows build of Inkscape (for obvious reasons of increased memory availability), and discovered the "effort" had already been done by the great people of MSYS2 and MinGW-w64. I would strongly suggest the Windows developers look into switching to this development platform instead of the current, manually maintained "devlibs" setup. Perhaps this suggestion can be made more plausible if I attempt to explain what MSYS2 and MinGW-w64 provide. MinGW-w64 is an active project that provides Win32 headers and libraries so that GCC can be used on Windows, both 32- and 64-bit. It has replaced "ye olde" MinGW.org on numerous Linux distros (most notably Debian, Fedora, OpenSUSE, Ubuntu, and Arch). It is also the toolchain distributed alongside the Qt SDK releases. MSYS2 is an updated version of the old MSYS (it takes a newer version of Cygwin, applies the MSYS patches, and presto: a Unix shell environment for building Unix/cross-platform software on Windows). Additionally, MSYS2 provides a complete repository of binary packages, linux-distro style. What the developers did was port Arch Linux' package manager, pacman, and create a whole ecosystem around it of ready-made MinGW-w64 packages. The full list can be found here. You'll notice that the list contains a mingw-w64-inkscape package. What this means is that there is an easy way of obtaining/building/... inkscape on Windows, without the need to jump through too many hoops. I'm not saying you guys should drop everything and come hide in the shade of MSYS2, but instead evaluate the current build process on Windows, and perhaps provide a simplified way of developing Inkscape on this platform. A free bonus would be the possibility of providing a 64-bit Inkscape build, which is already possible without any 64-bit Windows patches thanks to good code by you guys ;-). Also note that cross-compilation from Linux shouldn't be much harder either, all the aforementioned distros have an extensive list of MinGW-w64 libraries at their disposal, and using CMake should make it all "just work". The current wiki's instructions look abysmally complicated compared to the simplicity made possible by the MinGW-w64/MSYS2 combo. I strongly hope you take this into consideration, as it will lead to a lower entry for developing Inkscape on windows, which in turn will lead to quicker bug-fixing (I hope ;-)). Thanks and keep up the fine work! Ruben (known as rubenvb in the MinGW-w64 mailing community)

2 1

SVG2 hatch rendering
by Tomasz Boczkowski 05 Aug '14

05 Aug '14

Hi! I've implemented the rendering of SVG2 hatches in lp:~penginsbacon/inkscape/svg-paints-support. How it works can be seen using a test file attached to this message. The rectangles in left columns are filled with hatches, while the ones in right columns are reference images consisting of clipped paths. What is still to be done is to implement rendering when overflow property is set visible. In addition to this, I have to improve rendering when hatch covered object is zoomed out. The second problem can be seen in the picture [1]. The cause is aliasing when rendered cairo_pattern_t is applied to a shape. One of the solutions is to adjust applied pattern size to full pixels. This can be achieved by manipulating the transformation applied to the pattern by ink_cairo_pattern_set_matrix in drawing-pattern.cpp:119. The drawback of this rendering hatch paths at displaced positions, what can be visible in case of large shapes. Another solution is to allocate pattern surface of the size of object bounding box and to draw all hatch paths on it. The third one is to increase oversampling and use CAIRO_FILTER_NEAREST for hatches. What techique do you recommend? I'd like to add hatches to Swatches and Fill and Stroke dialogs and prepare stock hatches based on ISO 128-50 standard being used in Europe for technical drawing. As there are more SVG2 elements supported in Inkscape, how should fallback to SVG1.1 look like? Should there be an another output extension? In case of hatches should they be converted to patterns? Regards Tomasz

7 14

[GSOC Swatches] Latest code check in
by Tavmjong Bah 05 Aug '14

05 Aug '14

Hi Tomasz, I just looked at your latest code check-in. You've added in style.h: sigc::connection fill_ps_changed_connection; sigc::connection stroke_ps_changed_connection; to the already existing: sigc::connection filter_modified_connection; sigc::connection fill_ps_modified_connection; sigc::connection stroke_ps_modified_connection; How does "changed" differ from "modified"? This is a place where adding a comment or two would really be helpful to some future developer in understanding the code. Any progress with hatches? Tav

2 2