On Apr 7, 2011, at 7:43 PM, Krzysztof Kosiński wrote:

Update: color managed view should now work.

Rock!!!

2011/4/7 Krzysztof Kosiński <tweenk.pl@...400...>

Hello

I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?

Was building on OSX resolved as well? If not, that's still an outstanding bug too.

Cheers, Josh

On 8-4-2011 1:59, Krzysztof Kosiński wrote:

Hello

I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows.

Can you give specific people (like me :P) commit access, so I can help with the build problems?

Thanks, Johan

On 8-4-2011 22:30, Krzysztof Kosiński wrote:

2011/4/8 Johan Engelen<jbc.engelen@...2592...>:

...

Can you give specific people (like me :P) commit access, so I can help with the build problems?

Looks like there is now way in Launchpad to do this.

I'm not surprised...

I'm now uploading it with ~inkscape.dev as the owner.

Thanks. I've (temporarily) fixed the Windows build. I get a crash on startup and have to work around an assert. src/libnrtype/FontInstance.cpp, line 560: //g_assert(polyCurve->cpfx % 2 == 0); if (polyCurve->cpfx % 2 != 0) return;

One thing I noticed is funny: the diamond-shaped knots are not symmetric any more. The topleft edge is shorter than the others :) Not sure whether I like the "better looking" knots now. They look more part of the figure instead of part of the UI (the old ones are more pixelated, and 1 pixel stroked).

Ciao, Johan

W dniu 8 kwietnia 2011 22:30 użytkownik Krzysztof Kosiński <tweenk.pl@...400...> napisał:

Looks like there is no way in Launchpad to do this. I'm now uploading it with ~inkscape.dev as the owner.

The inkscape.dev-owned branch is now available at: lp:~inkscape.dev/inkscape/cairo-rendering

Regards, Krzysztof

W dniu 8 kwietnia 2011 23:46 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:

Cool. I have committed my build fixing changes. One final required thing I did not commit: I disabled some code in win32.cpp to get a complete build. But it really needs to be fixed, instead of disabled. Can you look into this Krzysztof?

/src/extension/internal/win32.cpp line 316 line 334 etc, use pixblocks, and should be converted to cairo stuff.

This has something to do with printing. I thought we were using Cairo and GtkPrint for this. Does anyone know how printing is done on Windows?

Regards, Krzysztof

W dniu 9 kwietnia 2011 01:56 użytkownik ~suv <suv-sf@...58...> napisał:

#0  0x02fbadfc in cairo_pattern_destroy () #1  0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2  0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x6887b70) at display/nr-style.cpp:140

0xf0f0f0f0 for "this" is obviously wrong, the stack is getting corrupted for some reason.

#3  0x00258941 in nr_arena_shape_set_style (shape=0x643ce00, style=0x6887b70) at display/nr-arena-shape.cpp:543

The "style" pointer looks correct here, so something went awry in nr_arena_shape_set_style. At the moment I have no idea what is going on.

Can you try compiling without optimization (-O0), or adding "g_return_if_fail(style != NULL);" at the top of nr_arena_shape_set_style()?

Regards, Krzysztof

On 9/4/11 02:12, Krzysztof Kosiński wrote:

W dniu 9 kwietnia 2011 01:56 użytkownik ~suv <suv-sf@...58...> napisał:

...

#0 0x02fbadfc in cairo_pattern_destroy () #1 0x0027edc7 in NRStyle::update () at display/nr-style.cpp:201 #2 0x0027edc7 in NRStyle::set (this=0xf0f0f0f0, style=0x6887b70) at display/nr-style.cpp:140

0xf0f0f0f0 for "this" is obviously wrong, the stack is getting corrupted for some reason.

...

#3 0x00258941 in nr_arena_shape_set_style (shape=0x643ce00, style=0x6887b70) at display/nr-arena-shape.cpp:543

The "style" pointer looks correct here, so something went awry in nr_arena_shape_set_style. At the moment I have no idea what is going on.

Can you try compiling without optimization (-O0), or adding "g_return_if_fail(style != NULL);" at the top of nr_arena_shape_set_style()?

Same error after 'make clean' and rebuilding with '-O0'.

~suv

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x03c77dfc in cairo_pattern_destroy () (gdb) bt #0 0x03c77dfc in cairo_pattern_destroy () #1 0x002e5e94 in NRStyle::update (this=0x713eec4) at display/nr-style.cpp:201 #2 0x002e6974 in NRStyle::set (this=0x713eec4, style=0x7587aa0) at display/nr-style.cpp:140 #3 0x002c0afb in nr_arena_shape_set_style (shape=0x713ee00, style=0x7587aa0) at display/nr-arena-shape.cpp:544 #4 0x001e00b3 in SPShape::sp_shape_show (item=0x72ada20, arena=0x5c83f80) at sp-shape.cpp:859 #5 0x0019f405 in SPItem::invoke_show (this=0x72ada20, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #6 0x001a64ff in CGroup::_showChildren (this=0x7587a00, arena=0x5c83f80, ai=0x5c85a00, key=1, flags=1) at sp-item-group.cpp:770 #7 0x001a667c in CGroup::show (this=0x7587a00, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:757 #8 0x001a89e7 in sp_group_show (item=0x72b0140, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:319 #9 0x0019f405 in SPItem::invoke_show (this=0x72b0140, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #10 0x001fa33a in sp_use_show (item=0x42c31a8, arena=0x5c83f80, key=1, flags=1) at sp-use.cpp:359 #11 0x0019f405 in SPItem::invoke_show (this=0x42c31a8, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #12 0x001a64ff in CGroup::_showChildren (this=0x6f00740, arena=0x5c83f80, ai=0x5c85c00, key=1, flags=1) at sp-item-group.cpp:770 #13 0x001a667c in CGroup::show (this=0x6f00740, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:757 #14 0x001a89e7 in sp_group_show (item=0x42e1218, arena=0x5c83f80, key=1, flags=1) at sp-item-group.cpp:319 #15 0x001db39a in sp_root_show (item=0x42e1218, arena=0x5c83f80, key=1, flags=1) at sp-root.cpp:622 #16 0x0019f405 in SPItem::invoke_show (this=0x42e1218, arena=0x5c83f80, key=1, flags=1) at sp-item.cpp:1045 #17 0x004d5ea8 in IconImpl::load_svg_pixels (names=@0xbfffeb94, psize=16, stride=@0xbfffeb90) at widgets/icon.cpp:1296 #18 0x004d8c51 in IconImpl::prerenderIcon (name=0x69b42cc "edit-select-all-layers", lsize=GTK_ICON_SIZE_SMALL_TOOLBAR, psize=16) at widgets/icon.cpp:1430 #19 0x004da3ca in Inkscape::queueIconPrerender (name=@0xbfffed00, lsize=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/icon.cpp:1339 #20 0x004e714a in create_action_for_verb (verb=0x430f840, view=0x5c80d80, size=Inkscape::ICON_SIZE_SMALL_TOOLBAR) at widgets/select-toolbar.cpp:387 #21 0x004e8d61 in sp_select_toolbox_prep (desktop=0x5c80d80, mainActions=0x6bf63f8, holder=0x42f50a8) at widgets/select-toolbar.cpp:405 #22 0x00533e7a in setup_aux_toolbox (toolbox=0x5d3b328, desktop=0x5c80d80) at widgets/toolbox.cpp:1901 #23 0x0051edc3 in Inkscape::UI::ToolboxFactory::setToolboxDesktop (toolbox=0x5d3b328, desktop=0x5c80d80) at widgets/toolbox.cpp:1667 #24 0x0056316f in Inkscape::UI::UXManagerImpl::connectToDesktop (this=0x690e030, toolboxes=@0xbffff054, desktop=0x5c80d80) at ui/uxmanager.cpp:230 #25 0x004b1355 in SPDesktopWidget::createInstance (namedview=0x42cc7f0) at widgets/desktop-widget.cpp:1476 #26 0x004b13a3 in sp_desktop_widget_new (namedview=0x42cc7f0) at widgets/desktop-widget.cpp:1425 #27 0x0009237b in sp_file_new (templ=@0xbffff19c) at file.cpp:125 #28 0x000926be in sp_file_new_default () at file.cpp:177 #29 0x00008071 in sp_main_gui (argc=1, argv=0xbffff2d0) at main.cpp:982 #30 0x000088f0 in main (argc=1, argv=0xbffff2d0) at main.cpp:717 (gdb)

On 9/4/11 03:48, Krzysztof Kosiński wrote:

W dniu 9 kwietnia 2011 03:30 użytkownik ~suv <suv-sf@...58...> napisał:

...

Same error after 'make clean' and rebuilding with '-O0'.

~suv

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xf0f0f0f4 0x03c77dfc in cairo_pattern_destroy () (gdb) bt #0 0x03c77dfc in cairo_pattern_destroy () #1 0x002e5e94 in NRStyle::update (this=0x713eec4) at display/nr-style.cpp:201 #2 0x002e6974 in NRStyle::set (this=0x713eec4, style=0x7587aa0) at display/nr-style.cpp:140

This looks like uninitialized memory in NRStyle. I added explicit NULL initializers in rev. 9588, see whether it fixes the crash.

Success! :)

Inkscape (cairo-renderer r9588) up and running on osx too (this is still with '-O0'). I'll do some tests and rebuild with '-O3' tomorrow, and maybe also a quartz-based version.

Thank you for making this work, ~suv

On 2011-04-09 0:12, Krzysztof Kosiński wrote:

W dniu 8 kwietnia 2011 23:46 użytkownik Johan Engelen <jbc.engelen@...2592...> napisał:

...

Cool. I have committed my build fixing changes. One final required thing I did not commit: I disabled some code in win32.cpp to get a complete build. But it really needs to be fixed, instead of disabled. Can you look into this Krzysztof?

/src/extension/internal/win32.cpp line 316 line 334 etc, use pixblocks, and should be converted to cairo stuff.

This has something to do with printing. I thought we were using Cairo and GtkPrint for this. Does anyone know how printing is done on Windows?

I just had a look (on Windows of course) and as far I can tell this code is unused. I can cut it out (as well as all relevant references and id's that I've been able to find) and I can still print. Apparently it used to have some function, and we even had a print preview and such, but I think at some point this was superseded by a new system and the old stuff was just left. In file.h there is even a comment that some print(preview) related functions are probably redundant, which apparently dates back to SVN(!!!) revision 1600-something.

In short: I'd like to try and cut out some of this apparently unused code, cleaning up our code base and "fixing" an issue with the cairo branch at the same time. But, it seems a little scary to just remove a whole lot of code that apparently at least used to have some function, so if anyone has a reason to keep this code around, please let me know.

On Fri, Apr 8, 2011 at 11:13 PM, Jon Cruz <jon@...18...> wrote:

On Apr 8, 2011, at 6:48 PM, Krzysztof Kosiński wrote:

...

This looks like uninitialized memory in NRStyle. I added explicit NULL initializers in rev. 9588, see whether it fixes the crash.

Well, since we're C++ we should be using 0 instead of NULL. :-)

But more importantly, this is exactly the sort of issue that Valgrind is very good at spotting and pointing out.

When problems like this (subtle corruptions or crashing) are hit, running under valgrind should be a first step. It will generally catch a problem when it first occurs, not later on after it has cascaded enough to actually cause a crash, etc.

If anyone needs more detail on the wiki for this, let me know. Also drop on in to IRC to hash it out (that really helps).

Krzysztof,

It appears that the new renderer doesn't release memory on zooming operations. Without any modifications to the document, just zooming in and out a number of times shows memory growth and memory that isn't released. If it's known and expected, okay, but it's just an observation I figured I would point out. The document I sent you off-list is a good test file for this behavior btw. (a follow-up to a valgrind reply seemed like it was a relevant place to comment)

Cheers, Josh

2011/4/9 ~suv <suv-sf@...58...>

On 10/4/11 00:29, Josh Andler wrote:

...

It appears that the new renderer doesn't release memory on zooming operations. Without any modifications to the document, just zooming in

and

...

out a number of times shows memory growth and memory that isn't released.

If

...

it's known and expected, okay, but it's just an observation I figured I would point out. The document I sent you off-list is a good test file for this behavior btw. (a follow-up to a valgrind reply seemed like it was a relevant place to comment)

Does you sample file contain (fairly complex) patterns?

Nope. Paths, LPEs, and filters.

Cheers, Josh

2011/4/9 Jasper van de Gronde <th.v.d.gronde@...528...>:

In short: I'd like to try and cut out some of this apparently unused code, cleaning up our code base and "fixing" an issue with the cairo branch at the same time. But, it seems a little scary to just remove a whole lot of code that apparently at least used to have some function, so if anyone has a reason to keep this code around, please let me know.

Kill it with fire.

The code was really bad in the first place, because it unconditionally rasterized the image before printing.

Regards, Krzysztof

On 8/4/11 01:59, Krzysztof Kosiński wrote:

I have updated my Cairo branch today, as a step towards merging it. There is one new regression, namely feImage does not handle aspect ratio. It will be fixed before merging. IIRC, there is a problem with CMS output, the editing controls are not using custom XOR blending, and there are build failures on Windows. Does anyone remember any other bugs?

a) outline view mode

cairo-renderer r9589, OS X 10.5.8 (i386), Apple's GCC 4.2.1, no OpenMP: - cairo 1.10.2, GTK+/X11 - cairo 1.11.2, GTK+/Quartz

Outline view mode uses white to draw the outlines: they are not visible on default backgrounds (white). The color of the outline apparently is not inverted (or xor-composited (?)) when using a dark background, either.

Currently, outline mode is only usable with a solid, darker background.

b) multi-threading / OpenMP

As described earlier [1], OpenMP is not detected by the configure script when building with Apple's GCC 4.2.1 (although the man page states otherwise, and e.g. 'libgomp.a' and the omp header do exist).

Testing a build of the cairo-renderer branch using plain GCC 4.2.4 installed via MacPorts does enable OpenMP (-fopenmp), but when used in rendering, Inkscape randomly hangs (apparently waiting for something to finish(?) - see attached backtrace when interrupting Inkscape after it no longer accepts any input).

The build with GCC 4.2.4 also produced several warnings from the linker ("ld warning: can't find atom for N_GSYM stabs (...)").

I will try with newer GCC versions [2], but so far my earlier tests building inkscape trunk with GCC 4.5 and GCC 4.4 had other serious issues (crashes, or e.g. broken text rendering on canvas).

IMHO with the new renderer, we should get OpenMP working on OS X as well. Any input or help - maybe it just needs adjusted compiler and linker flags (?) - would be appreciated.

~suv

[1] http://article.gmane.org/gmane.comp.graphics.inkscape.devel/34491 [2] currently installed GCC versions (XCode 3.1.4, MacPorts): gcc-4.0 (4.0.1, Apple) gcc-4.2 (4.2.1, Apple) gcc-mp-4.2 (4.2.4, MacPorts) gcc-mp-4.3 (4.3.5, MacPorts) gcc-mp-4.4 (4.4.5, Macports) gcc-mp-4.5 (4.5.2, MacPorts)

Program received signal SIGINT, Interrupt. 0x90d8444e in __semwait_signal () (gdb) bt #0 0x90d8444e in __semwait_signal () #1 0x90daf3e6 in _pthread_cond_wait () #2 0x90daedcd in pthread_cond_wait$UNIX2003 () #3 0x1386589c in gomp_sem_wait () #4 0x13865993 in gomp_barrier_wait_end () #5 0x138659f9 in gomp_barrier_wait () #6 0x1386511d in gomp_team_start () #7 0x138648cf in GOMP_parallel_start () #8 0x0029b25b in Inkscape::Filters::filter2D_FIR<unsigned char, 4u> (dst=0x4 <Address 0x4 out of bounds>, dstr1=<incomplete type>, dstr2=<incomplete type>, src=0x1acd5030 "", sstr1=<incomplete type>, sstr2=<incomplete type>, n1=<incomplete type>, n2=<incomplete type>, kernel=0xbfffdcc0, scr_len=<incomplete type>, num_threads=<incomplete type>) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/complex:954 #9 0x0029b44c in Inkscape::Filters::gaussian_pass_FIR (d=<incomplete type>, deviation=<incomplete type>, src=<incomplete type>, dest=<incomplete type>, num_threads=<incomplete type>) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/complex:954 #10 0x0029bc80 in Inkscape::Filters::FilterGaussian::render_cairo (this=0x1ac92190, slot=<incomplete type>) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/complex:954 #11 0x0029527b in Inkscape::Filters::Filter::render (this=0x1a9262d0, item=0x1a92a1c0, bgct=0x15769594, bgarea=0xbfffe354, graphic=0x15769a68, area=0xbfffe1e4) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/ext/new_allocator.h:89 #12 0x00280113 in nr_arena_item_invoke_render (ct=0x15769594, item=0x1a92a1c0, area=0xbfffe354, pb=0x0, flags=0) at display/nr-arena-item.h:73 #13 0x00278d88 in nr_arena_group_render (ct=0x15769594, item=0x1a929700, area=0xbfffe354, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #14 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1a929700, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #15 0x00278d88 in nr_arena_group_render (ct=0x157690c0, item=0x1912d900, area=0xbfffe85c, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #16 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1912d900, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #17 0x00278d88 in nr_arena_group_render (ct=0x157690c0, item=0x1912dd00, area=0xbfffe85c, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #18 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1912dd00, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #19 0x00278d88 in nr_arena_group_render (ct=0x157690c0, item=0x1910c000, area=0xbfffe85c, pb=0x0, flags=0) at ./display/nr-arena-item.h:73 #20 0x0027fd81 in nr_arena_item_invoke_render (ct=0x157690c0, item=0x1910c000, area=0xbfffe85c, pb=0x0, flags=0) at display/nr-arena-item.h:73 #21 0x0025839a in sp_canvas_arena_render (item=0x191bd5b0, buf=0xbfffe9e0) at display/canvas-arena.cpp:64 #22 0x002b2142 in sp_canvas_group_render (item=0x18e5f1c0, buf=0xbfffe9e0) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #23 0x002b2142 in sp_canvas_group_render (item=0x18e5f130, buf=0xbfffe9e0) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #24 0x002b0c5a in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = -320}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #25 0x002b0670 in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = -272}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #26 0x002b0670 in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = -176}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #27 0x002b0670 in sp_canvas_paint_rect_internal (setup=0xbfffedf4, this_rect={x0 = -16, y0 = -368, x1 = 704, y1 = 10}) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #28 0x002b3826 in sp_canvas_paint_rect (canvas=0x191efa48, xx0=-16, yy0=-368, xx1=704, yy1=16) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #29 0x002b3d04 in do_update (canvas=0x191efa48) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #30 0x002b61a8 in idle_handler (data=0x191efa48) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/boost/optional/optional.hpp:640 #31 0x15ae671d in g_main_context_dispatch () #32 0x15aea5ab in g_main_context_iterate () #33 0x15aea887 in g_main_loop_run () #34 0x13eaefa1 in gtk_main () #35 0x138c2d4b in Gtk::Main::run () #36 0x000058fa in sp_main_gui (argc=1, argv=0xbffff2d0) at /Volumes/green/mp-inkscape/with-a-long-long-long-directory-name/include/gcc42/c++/bits/basic_string.tcc:146 #37 0x00003e9b in _start () #38 0x00003dc9 in start () (gdb) quit The program is running. Exit anyway? (y or n) y LeWitt:mp-inkscape suv$