Inkscape crashes on Effects: render: grid without default

- cannot reproduce this on Windows XP, Inkscape 0.47pre3.
- would you be willing to try a more recent version, available at :
http://sourceforge.net/projects/inkscape/files/

the current development version has two options for grids:
a) Extensions->Render->Grid (which is probably what you are using)
b) Extensions->Render->Cartesian Grid

'Render > Grid' (internal extension, not python-based) still has the bug when applied to a selected rectangle (bug #401567), but I don't know if this is related.

@BigOldNerd - there is only one prerelease build for Tiger available: 'Inkscape-0.47-pre1-1.TIGER-Intel.dmg' from <http://sourceforge.net/projects/inkscape/files/inkscape/0.47pre1/>

If the crash still happens with 0.47pre1 Tiger, could you attach the crash log and any related log messages you see in when you open 'Console.app' (in 'Applications > Utilities') and select the 'All messages' entry in the log list?

Neither version works.
Alvin-the one you recommended won't run on my version of the OS.
suv-the one you recommended tries to launch, and launches X11, but Inkscape won't come up. Now that I look carefully, I see it won't work, I don't have the Intel processor...

(sorry - completely forgot that Inkscape-0.47pre1-1 TIGER isn't a universal build...)
I cannot reproduce your crash with Inkscape 0.46-2 Leopard either. Which version do you have currently installed?

suv - no problem, I'm using Inkscape-0.46-3.TIGER.UNIVERSAL

You could still attach the crash report and any related console messages (hopefully someone will package a 0.47 version for Tiger (universal) and it might help to know more details about your crash). To me it looks like either
a) the bug has been fixed since the release of 0.46, or
b) it's a ppc-platform-specific error of the 0.46-3 build that hasn't been noticed before (I searched the bug database up and down, but didn't come up with any previous report - both effects-grid-related or tiger-effects-related)

I have a little more information...

When it locks up (?), it does not send a message to the console. The window I thought was an error window is the window that appears while it is rendering.

It does not lock up when the default measurement is in px, only when in inches.

setting the default unit to 'in' doesn't make a difference here with Inkscape 0.46 and 0.47pre.

Could you start Inkscape from the command line to see if you get any error messages?
Keep X11 running, but quit Inkscape. Open 'Terminal.app' and type:
   /Applications/Inkscape.app/Contents/MacOS/Inkscape
(replace /Applications with the path to your installed Inkscape application)

any console messages should now be printed in the terminal window. (To kill the program if it doesn't respond to 'Quit' anymore you can use 'ctrl+c'.)

I think I figured out the problem. If you set the value of the spacing to less than 2, it starts to have trouble rendering. It didn't lock up at 1.9, but the grid was overwhelming the area (at 750% magnification you could see squares, but the grid lines were larger than the squares). The setting that triggered the problem was .2. I think the grid lines are too close together and the program can't finish rendering. (The first time I tried it at that setting I waited over an hour and it didn't respond.) It is not sending an error out (even under the terminal) because it is still trying to figure out how to draw the requested spacing.

Thank you all for your time and efforts!

so, is it alright to close this bug?

I think so.
I think it would be a good idea to include something in the documentation warning against making the divisions so fine.
It might also be nice to be able to change the units for the grid lines too :-)

@BigOldNerd - the FAQ is part of a Wiki… ;-) I confess I didn't think of entering values that small when testing - I stayed in the range of 5 up and 5 down approximately for the spacing values.

But now I have Inkscape calculating a grid (in inches with spacing set to 1.0/1.0) and it eats up all memory it can get and almost freezes my laptop to a stand-still. Confirming this bug as severe performance issue that would better be addressed by either removing the now (0.47pre) redundant extension or rewriting the code with sensible limits to the grid density and / or grid layout.

Can someone from the bug team raise the level of importance for this bug?

forgot: tested with Inkscape 0.46+devel r 22389 on OS X 10.5.8 (2GB RAM), did force quit the application.

@suv I only entered that value because I thought the measurements were in inches and I wanted a .25inch spacing for my grid...silly me LOL
Thanks

Crash reproduced on Ubuntu 9.10, Inkscape bzr rev. 9360.

Reported on #inkscape irc channel:

Miraceti wrote:
> I have noticed a bug in 0.47 and 0.48. When running
> Extension->Render->Grid, it is possible to enter horizontal
> and/or vertical spaces = 0 which causes 100% CPU usage in
> apparently neverending loop.

> Well, experiencing problems with small values could be unpleasant
> but zero should not definitely be tried to render at all.

> Division by zero is much worse than just consuming a lot of memory.

> I guess, zero should be filtered out already on UI level.

on Windows XP, Inkscape 0.48 I am not allowed to use the value of 0 for the spacing. The smallest number I can achieve is 0.1, if I type in 0 it is overwritten with 0.1

however, 0.1 is enough to hang up my machine for more than a minute...

Like Alvin I cannot enter a value < 0.1 for the spacing (0.47, 0.48 and 0.48+devel r9784) on OS X 10.5.8, using (fallback) C locale and the 'System default' language in Inkscape, or when changing the UI language within Inkscape to German or French (decimal separator stays '.').

The lower limit to '0.1' doesn't seem to be in effect with certain locale setting (LC_NUMERIC): a comma as decimal separator apparently allows to enter '0,0' into the dialog:

Reported on irc by Miraceti with
Linux jiri1 2.6.35-gentoo-r4 #1 Sat Sep 4 13:26:57 EEST 2010 i686 AMD Athlon(tm) XP 1800+ AuthenticAMD GNU/Linux
LC_NUMERIC=cs_CZ.UTF-8
gentoo package media-gfx/inkscape-0.48.0 (marked unstable in Gentoo now)

Also confirmed by sanguivor (on irc) for the bzr version: Locale is a mixture of en_DK.UTF-8 and fi_FI.UTF-8.

Reproduced with Inkscape 0.48+devel r9784 on OS X: If I change the language ($LANG) for the Inkscape process so that comma is used as decimal separator, the lower limit (0.1) no longer applies (see attached screenshot).

The min/max values are defined in the extension definition file:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/annotate/head%3A/src/extension/internal/grid.cpp#L194>

            "<param name=\"xspacing\" gui-text=\"" N_("Horizontal Spacing:") "\" type=\"float\" min=\"0.1\" max=\"1000\">10.0</param>\n"
            "<param name=\"yspacing\" gui-text=\"" N_("Vertical Spacing:") "\" type=\"float\" min=\"0.1\" max=\"1000\">10.0</param>\n"

Ignoring the min/max float values depending on decimal separator is possibly a similar issue as bug #571196.

Issue with decimal separator filed as new report:
Bug #647744 “[inx] min/max float values ignored with locale using comma as decimal separator”
<https://bugs.launchpad.net/inkscape/+bug/647744>

Patch attached in report Bug #647744.

Oops, I thought this report was a special case of Bug #647744, but it is about performance.
Anyway, I didn't manage to reproduce the crash with 0.48 and the recent dev. versions, but had to kill the task when the spacing values were too low.

Tested again on Windows XP.
With 0.48.4, it's still slow (about 10 seconds to render with 3px spacing) and eats lots of RAM (almost a Gio).
With trunk revision 11992, it renders very quickly and doesn't over-consume the computer resources.
The new renderer rocks!