Hello,

I'm trying to make a hexagon grid with 184,471 objects (184,110 hexes, 361 squares). Initially, I tried this with clones. Upon trying to copy the original object, I was able to create a total of 38,836 objects. I thought that the clones were the cause of the issue, so I remove the clones and repeated the process. This resulted in 48,545 objects.

Upon trial and error, I was able to reproduce the 184,471 objects. The file size was 179,904 KB. Converting it to straight SVG, 95,875 KB. However, each time that I scroll out to see the entire object, I get errors and the application crashes. This happens when Inkscape hits about 2 GB of memory through the Task Manager.

Obvsiously, based on the error messages below, I'm running out of memory. Is there a way to allow more memory to be consumed? I've vacuumed defs and removed extra code from the SVG file. Is there a way to further reduce the size of the file?

Any help is appreciated!

Thanks

System:
Win 7 64-bit
6 GB RAM
Pentium Dual-Core E5800 @ 3.20GHz

Error 1:
Title: "Error"
Message: GLib-ERROR **: gmem.c:170:failed to allocate XXXX bytes aborting...

Error 2:
Title: "Microsoft Visual C++ Runtime Library"
Message: This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

Error 3:
Title: "Microsoft Visual C++ Runtime Library"
Message: GLib-ERROR **: gmem.c:170:failed to allocate XXXX bytes aborting... ** WARNING (recursed) **: GC Warning: Out of Memory! Returning NIL! aborting...

After doing a little more research, it looks like I'm pretty much limited to that 2 GB cap. Are there plans for a 64 bit version?

Thanks!

I'm currently working on an image with 35,865 objects. And they are aligned like a grid. I'm not doing anything too strenuous with them, such as moving around. Mosting I'm just changing colors. But I've been able to manage the slowdowns by grouping large chuncks at a time, while I'm not working with them. This greatly reduces the number of objects, and apparently allows things to run more smoothly.

I'm on Windows 7, 64-bit, 4 gb RAM, Intel Core i7, Q 720 @ 1.60 GHz. Quite a bit less of a system than yours! This is Inkscape v 0.48.1, and I haven't had any crashes. Slowdowns, YES. My file size is currently 6.3 mb, but I have an imported raster which I think is a BMP. So that probably has inflated the size. (I'm not sure if simply changing colors will change than much? I'm guessing not much.) And I haven't experimented with reducing file size, because grouping seems to work for me. Of course, your 184,471 objects is roughly 5 times mine. But maybe you could use the same strategy, and group most of what you're not working on at the moment?

Just a thought....and some info for comparison

You may be right on the complexity. There's a lot of "transform"s in the document. I'm sure that's the majority of the file size.

As far as the grouping, I have already tried that. Each group of 511 is grouped, and then each group of 19 is also grouped. No luck.

Thanks for the ideas!

Well, I attempted to recreate the image and scaled out to see the whole picture. When duplicating the 5th set of items, the program crashed. What was odd, the current image is only 18,356 KB. This would be about 73 MB, about 2.5 times smaller than the original image, and it still stalled at 2 GB RAM. The issue must be in the rendering of the picture.

Would anyone care to try the file? The file is too large to upload here, so it is on my website. Open the SVG file and open it in Inkscape. Duplicate the bottom 19 columns. This is where I get the error. Task Manager on my machine will be about 1.631 GB memory before duplicating.

Any help is appreciated!

Thanks

Ok, well I don't know if I learned anything substantive. I was able to save and open the file. My first attempt, I'm pretty sure it did successfully duplicate the objects. But instead of confirming it by other means, I tried to move them aside and immediately Inkscape crashed. In subsequent attempts, it crashes during the duplication. I think I could probably restart my system and do another successful duplication, if there is anything we might learn by doing so. Just let me know what to look for (I don't really understand much of this ).

Inkscape saved me the auto backup files, but I can't open them. Or more specifically, Inkscape tries to open them, but crashes before the contents are displayed.

I've received the same error messages as you, except this one:

GLib-ERROR **: gmem.c:170:failed to allocate XXXX bytes aborting...

Mine said

GLib-ERROR **: gmem.c:175:failed to allocate XXXX bytes....

Probably that's not significant, but since I don't understand it, I'm just reporting it.

I HAVE been able to duplicate smaller numbers of groups than 19, but haven't determined the largest number. So duplicating in smaller batches might work for a while. But I would guess that you'd eventually hit the same wall.

I don't know what your ultimate goal is, but I wonder if it might work to create several smaller files, and then assemble them in another program, to create the one huge file?

I'd like to avoid the smaller files. My main goal is to have a large size map. Maybe running Inkscape on a Linux box would help?

I'm not sure this is a bug. It seems to be a limitation of the program. Just unfortunate. I appreciate you trying out the file. Makes me feel better knowing it's not just me

I downloaded your file, selected all objects, and pasted them twice. After saving the file is now 54 MB, but I forgot to count the number of objects. It took me about half an hour on my 3 year old AMD quadcore, but at least Inkscape didn't crash.

This could be relevant: only 4 GB of RAM, but running a development build of Inkscape on 64 bit Linux (Fedora 15).

Some things that you could try to speed things up a bit:
- Turn off snapping
- Preferences: Tools -> Selector -> Geometric Bounding box
- View in outline mode

dvlierop, you said you pasted your objects. When I tried, I was duplicating. Does copy/paste somehow reduce the file size?

dvlierop wrote:Some things that you could try to speed things up a bit:
- Turn off snapping
- Preferences: Tools -> Selector -> Geometric Bounding box
- View in outline mode

Outline mode did pass through my mind, but after seeing the file, and that they were just stroked paths anyway, it didn't seem like it would help. But would outline mode help in this case? Does it remove all the stroke and color data? And how does using the geometric bounding box help? Same reason?

I'm gonna try again using copy/paste....

Ok, well the copy was successful. I just tried copying that same last row. But as soon as I pasted, it crashed, with 2 different errors reported. Here's a screen capture of those:



I have no idea what they mean. I'm just providing the info in case it might be helpful.

Now I'll try again, with dvlierop's suggestions (yes I can be stubborn, lol)

Ah-HA!
With Outline mode, I can successfully duplicate AND move them around (the last row of 19 groups). It is very slow moving them -- I have to move the mouse and wait for them to catch up. I didn't try the bounding box change, but I suspect that with it, you will be able to duplicate and move at least a few more rows. Based on how slowly they move on my system, I suspect you won't be able to make the full size you desire though

But if you're able to use Linux, then based on dvlierop's test, together will all the modifications, maybe it will work? Good luck

Meanwhile, it hasn't been answered as to what Inkscape's limitations are. Is it file size, dimensions, number of objects? It appears to vary according to operating system, but I think it would be interesting to know what they are. (yes, stubborn and curious, lol!)

brynn wrote:Meanwhile, it hasn't been answered as to what Inkscape's limitations are. Is it file size, dimensions, number of objects?

You really think such numbers exist?

Based on my own tests, the major difference between what dvlierop reports, and the other tests done on Windows is the version of Inkscape:

Diederik used development builds with the new renderer and several memory leaks fixed (only draw-back: stroked paths are slow, at the moment, to be manipulated on-canvas).

I tested both the stable and development builds (on Mac OS X, 32bit) and can confirm the difference is huge (specially, if I modify the original drawing to have unstroked, solid filled paths - at least during creation of the layout).


The drawing redone using one original group (with the 510 hexgons + 1 rectangular path) and a grid of 19x8 clones (152 clones in total) results in a file size of 152 KB (remember: the original file was 17.9 MB):

19x8test-r10639.svg

(149.25 KiB) Downloaded 301 times

Note: I do not recommend to open that drawing with current stable Inkscape 0.48.2 (there are simply too many paths to be drawn (closely overlapping or with coinciding edges) - the lower file size doesn't change that fact).

Note II: The original group is hidden on a separate layer -> only the clones are visible (and the stroke of the rectangle in the original group has been unset)

Recent development snapshots (>r10588) I would only recommend with optimized builds (not debug ones without optimization) until the calculation of stroked paths has been sped up [see 2)]. Even then you probably want to find ways to optimize drawing such grids (fewer elements, no redundant edges) if you plan to create your actual drawing on top of it (using the grid as layout / snapping help.

As seen in a recent development build (takes about 40 sec to open the file on a 32bit system with 2.4 GHz Intel C2D and 2GM RAM):

Code: Select all

$ time inkscape -f /tmp/19x8test-r10639.svg --verb=FileClose

real   0m54.701s
user   0m47.752s
sys   0m1.632s


brynn wrote:(…) When I tried, I was duplicating. Does copy/paste somehow reduce the file size?

No. It does not make a difference with regard to file size. Only creating a clone would and then duplicating the clone (Note: do not make nested clones i.e. do not clone a clone, always duplicate it instead).

brynn wrote:Outline mode did pass through my mind, but after seeing the file, and that they were just stroked paths anyway, it didn't seem like it would help. But would outline mode help in this case?

Yes. It does make a huge difference (in stable 0.48.2 as well as in recent development builds).

brynn wrote:And how does using the geometric bounding box help?

Not really - AFAIU the renderer is the slowest part, the selection bbox mode doesn't change a lot (not even with the development builds which really have a -known- performance issue at the moment when calculating the (much more precise) visual bbox of stroked objects).

You really think such numbers exist?

Based on my own tests, the major difference between what dvlierop reports, and the other tests done on Windows is the version of Inkscape:

Diederik used development builds with the new renderer and several memory leaks fixed (only draw-back: stroked paths are slow, at the moment, to be manipulated on-canvas).

I tested both the stable and development builds (on Mac OS X, 32bit) and can confirm the difference is huge (specially, if I modify the original drawing to have unstroked, solid filled paths - at least during creation of the layout).

~suv, you know I don't understand the technical side of Inkscape, and struggle to keep up with it. I know that a new renderer is coming, but had no clue that it was in the dev builds already. I do my best to learn from as well as to help other Inkscape users. tdewitt274 seemed to think there might be some known limits, and while I think we all managed to help (him or her) in some way, that particular question, which seemed to me to be the heart of the issue, had not been addressed. I was curious as well, and I don't apologize for not already knowing the answer.

But thanks for replying and providing all those answers. You always help me to understand more, and I appreciate it.