Shrinking a pattern causes lock-up

[Hans Nieser]

I have an SVG document, created with Inkscape (attached
as 1.svg), in which turning just about any path into a
pattern and then shrinking the pattern using any of the
transformation handles (horizontal/vertical/both)
results Inkscape using 100% CPU and a non-responsive
desktop (Gnome 2.12 in my case). Oddly enough, when I
create a new SVG document file I can't reproduce it as
easily. Also, sometimes it would just hang for a few
seconds but most of the time (seemingly) forever. I've
spent a few hours trying to narrow down what causes it
but this is the best I could do:

To reproduce:

- Open attached SVG document (1.svg).

- Use existing triangle, or create a new path, with or
without fill and/or stroke (any combination seems to
work) of any complexity. *

- Turn the path into a pattern (object(s) to pattern).

- Grab any of the scaling transformation handles on the
pattern and gradually shrink it until it hangs. **

* Actually, not all shapes seem to cause the hang, I
noticed that it doesn't happen on shapes where the
edges are curved outward and no nodes are touching the
bounding box. When I use a new SVG document and start
from scratch it seems almost impossible to cause the
hang, but occasionally it does hang.

** Although the hang occurs with the grid+snap turned
on, with certain shapes and complexities it seems to
only happen (or at least more easily) with snap turned off.

I've tested this with both .43 and latest from svn
(checked out April 9 2006 8:14 CEST)

[Rwst (rwst)]

thanks for the report. confirmed on OpenSuSE. it appears to
be stuck while rendering.

Program received signal SIGINT, Interrupt.
nr_R8G8B8A8_N_R8G8B8A8_N_R8G8B8A8_P (px=0x912ccf8 "", w=2,
h=82, rs=8,
    spx=0xa00e320 "", srs=8, alpha=255) at nr-compose.cpp:192
192 a = NR_PREMUL (s[3], alpha);
#0 nr_R8G8B8A8_N_R8G8B8A8_N_R8G8B8A8_P (px=0x912ccf8 "",
w=2, h=82, rs=8,
    spx=0xa00e320 "", srs=8, alpha=255) at nr-compose.cpp:192
#1 0x0834aa2a in nr_blit_pixblock_pixblock_alpha
(d=0xbfa5fcac, s=0xbfa5fb60,
    alpha=255) at nr-blit.cpp:107
#2 0x082f8169 in nr_arena_item_invoke_render (item=0x9ff7c58,
    area=0xbfa5fcc8, pb=0xbfa5fcac, flags=0) at
nr-arena-item.cpp:317
#3 0x0819257a in sp_pat_fill (painter=0x9ffc028, pb=0xbfa5fd48)
    at sp-pattern.cpp:973
#4 0x082f6182 in nr_arena_render_paintserver_fill
(pb=0xbfa601a0,
    area=0xbfa5fd2c, painter=0x9ffc028, opacity=1,
mask=0xbfa5fdc8)
    at nr-arena.cpp:115
#5 0x082fd1c6 in nr_arena_shape_render (item=0x9fd4b90,
area=0xbfa5febc,
    pb=0xbfa601a0, flags=1) at nr-arena-shape.cpp:695
#6 0x082f860d in nr_arena_item_invoke_render (item=0x9fd4b90,
    area=0xbfa5ffbc, pb=0xbfa601a0, flags=<value optimized out>)
    at nr-arena-item.cpp:644
#7 0x082f9080 in nr_arena_group_render (item=0x9fd4b90,
area=0xbfa5ffbc,
    pb=0xbfa601a0, flags=1) at nr-arena-group.cpp:193
#8 0x082f860d in nr_arena_item_invoke_render (item=0x9fb73b8,
    area=0xbfa600bc, pb=0xbfa601a0, flags=<value optimized out>)
    at nr-arena-item.cpp:644
#9 0x082f9080 in nr_arena_group_render (item=0x9fb73b8,
area=0xbfa600bc,
    pb=0xbfa601a0, flags=1) at nr-arena-group.cpp:193
#10 0x082f860d in nr_arena_item_invoke_render (item=0x9ca7798,
    area=0xbfa601bc, pb=0xbfa601a0, flags=<value optimized out>)
    at nr-arena-item.cpp:644
#11 0x082f9080 in nr_arena_group_render (item=0x9ca7798,
area=0xbfa601bc,
    pb=0xbfa601a0, flags=1) at nr-arena-group.cpp:193
#12 0x082f860d in nr_arena_item_invoke_render (item=0x8719ed8,
    area=0xbfa6024c, pb=0xbfa60230, flags=<value optimized out>)
    at nr-arena-item.cpp:644
#13 0x08300727 in sp_canvas_arena_render (item=0x8719cc0,
buf=0xbfa602ec)
    at canvas-arena.cpp:281
#14 0x0830e94d in sp_canvas_group_render (item=0x871c1e0,
buf=0xbfa602ec)
    at sp-canvas.cpp:803
#15 0x0830e94d in sp_canvas_group_render (item=0x86d85f0,
buf=0xbfa602ec)
    at sp-canvas.cpp:803
#16 0x0830f671 in sp_canvas_paint_rect (canvas=0x86ea7d8,
xx0=384, yy0=-2816,
    xx1=448, yy1=-2688) at sp-canvas.cpp:1575
#17 0x08310178 in do_update (canvas=0x86ea7d8) at
sp-canvas.cpp:1754
#18 0x0831028b in idle_handler (data=0x86ea7d8) at
sp-canvas.cpp:1796
#19 0x40f84941 in g_child_watch_add () from
/opt/gnome/lib/libglib-2.0.so.0
#20 0x40f8235c in g_main_context_dispatch ()
   from /opt/gnome/lib/libglib-2.0.so.0
#21 0x40f857cb in g_main_context_check () from
/opt/gnome/lib/libglib-2.0.so.0
#22 0x40f85ae7 in g_main_loop_run () from
/opt/gnome/lib/libglib-2.0.so.0
#23 0x404ee861 in gtk_main () from
/opt/gnome/lib/libgtk-x11-2.0.so.0

[Hans Nieser (hnsr)]

In hindsight, Gnome doesn't actually lock up, but I am
unable to use the mouse because Inkscape has taken 'control'
of it (not sure what the right term is here), Gnome keyboard
shortcuts still work. Just to clear that up :)

[Bryce Harrington (bryce)]

Bumping to 9 since rwst says this is release critical.

[Rwst (rwst)]

this happens only if the line in your file exists

patternTransform="matrix(0.99505,0,0,0.99505,99.5,99.5)"

I'm not the expert on this, so reassigning...

[Bryce Harrington (bryce)]

Originator: NO

Can someone check against a recent build and see if this problem is still
there?

[Hans Nieser (hnsr)]

Originator: YES

I'm sorry to report that I can still reproduce this problem using the
latest from SVN :(

[Diederik van Lierop (mail-diedenrezi)]

Does anyone have a copy of the file? The attacment didn't get copied over from the sourceforge bugtracker. I've tried to reproduce this bug by creating my own file, but I wasn't very succesfull :-)

[vonHalenbach (lustik)]

It is attached. Please look on the left side. Thank you for working on it. :)

[Bryce Harrington (bryce)]

Milestoning for 0.46. Diederik, if you look into this can you report back what looks like it'll take to fix it?

[Diederik van Lierop (mail-diedenrezi)]

OK, I've found the file and can confirm that this bug is still present :-(

[Diederik van Lierop (mail-diedenrezi)]

When the handle that is being dragged comes too close to the scaling origin, an extreme transformation will result. This triggers a virtually infinite loop during rendering. I've solved this by simply blocking the rendering of the pattern in such an extreme case. I'm quite sure that this solves the problem, so I've changed the status to "Fix Released". If the bug however hasn't been fully squashed then don't hesitate reopening this bug!

For more details please refer to:
http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=16861