File takes over 60 seconds to save?

[maisieinforestburg]

Hi, I just made a file with some star shapes, with blurs on them - I copied and sprayed swooshes of these onto a 12x12 black background. I made a couple different versions of them, and noticed that when I went to export them in png format, it took over 60 seconds to save them to the desktop and if I tried to save them to an external drive, inkscape simply stopped responding.
Is this normal for big files? They're not that big though, most of them were 2.77 mb at the most.

Thanks !

[brynn]

Hhm, no I don't think they should be taking so long to export.  Let me dig up a large file for testing, and I'll be back.  Are you using 0.92.2 (the current stable version)?

[brynn]

Hhm, no, it only took a couple of seconds to export a 2 mb SVG.  If this is on the current stable version, I'll look and see if there are any reported bugs.  If it's not the current stable......

Ooh, I just remembered.....was that you who was having a hard time upgrading?  Maybe was someone else.  I was going to suggest upgrading to see if it's fixed.

[Lazur]

2,77 MB is not small for a regular file. Maybe there are unused definitions inside? Would try file/cleane up document.
It's not that large though either. My guess is every blurred objects have a separate blur filter definition.
If the objects don't overlap, instead of blurring them one by one, grouping them together and blurring the group would be more "space-efficient".

60s is a good responding time. If you export the screen at a 96 dpi resolution, theoretically that would take the same amount of time zooming in for 100% zoom level.
In that manner, if you export at double resolution, it would take as much time as rendering the image on screen at 200%. Probably at some zoom level the area you want to export is larger than the one rendered on screen, but as a basic compare you can test with the zoom level rendering the blurring takes exponentially larger amounts of time.

Can show you svg-s that take 30 mins at least to export as the result of extensive use of filtering. And there are others which just melt the renderer right away.


The second issue, rendering to an external drive, I'm not sure of. My guess is the writing speed of the pendrive is smaller than what inkscape can perform upon exporting and the computer cannot handle/refuses to handle cached datastream of the saving process.


Doubt if a different inkscape version would give a boost to the performance. Only difference I know of is linux systems have inkscape work a bit faster.
For performance testing, made a collection of all sorts of svg-s here.

[brynn]

I think I saw a bug about this (for 0.92.2), but I'm waiting to hear which version she uses.  If it's a bug, a different version probably would help.

Although to be honest, I've never tried to save directly from Inkscape to another drive.  I wouldn't think it would be a problem, but I'm not a bug expert.

[maisieinforestburg]

I am using .48 version - I had downloaded the new version 2x, but had the same issue, so went back to .48.....

I've attached an SVG of the file. SvG files save fine, in a couple seconds. Export to png at 300 dpi is the problem, taking over 60 seconds to save to desktop, and inkscape not responding to my external e-book drive.

[Lazur]

Using radial gradients instead of blurring can result in a better performance. This file is using gradients only.

[maisieinforestburg]

When I made the circles the solid white ones, I went to object > stroke and fill > blur - I'm a bit confused, I didn't use a radial fill - are they the same?

[Lazur]

No. Blurring is a filter which you can also access by the slider in the fill and stroke panel (Shift+Ctrl+F).
Filters are added into the rendering as a "second pass". Once the vector content is rendered, it is treated as a raster image, and the filter takes that in as an input and outputs a visual modification.
In general, they are resource heavy, and blurring takes exponentially more resourcing power with the same amount of zooming in.

Contrary, gradients are kept in a "computing-friendly" manner. Instead of performing infinite amount of calculations to determine averages of a blurred pixel, gradients rather use another algorithm to interpolate colour values between gradient steps.
Method also takes in some bitmap-based approach -reason why eps cannot save gradients (?)- but it's way convenient for the renderer.

No, they are not the same, I drew them trying to make a close appearance.

[brynn]

Ok, with 0.92.2, I tried exporting at 300 dpi to the desktop.  It took about 5 seconds.  I think I might still have a copy of 0.48, I'll try with that.

Yes, with 0.48, it took about 30 seconds to export.  I didn't try exporting directly to an external drive, because there's an easy way around that -- simply save it anywhere and then copy it over to the drive.  That takes Inkscape out of the loop.

Since the problem is not with 0.92.2, the bug that I thought I saw would not be a factor.  So the next thing I would suspect would be your computer's resources.  Do you know how much RAM you have?  I'm pretty sure Inkscape uses RAM for exporting.  If you have an older computer, with....let's say 2 GB RAM or less, that could explain the slowness.  (I have....I think 8 GB of RAM.)

Lazur was just suggesting that if you use gradients instead of blurring, it might speed up the export.  You should be able to get something similar with a gradient.

In any case, if the slowness is attributable to your computer's resources, there's not much we can do, except for suggest ways you can reduce the file size, export faster, etc.

[maisieinforestburg]

No. Blurring is a filter which you can also access by the slider in the fill and stroke panel (Shift+Ctrl+F).
Filters are added into the rendering as a "second pass". Once the vector content is rendered, it is treated as a raster image, and the filter takes that in as an input and outputs a visual modification.
In general, they are resource heavy, and blurring takes exponentially more resourcing power with the same amount of zooming in.

Contrary, gradients are kept in a "computing-friendly" manner. Instead of performing infinite amount of calculations to determine averages of a blurred pixel, gradients rather use another algorithm to interpolate colour values between gradient steps.
Method also takes in some bitmap-based approach -reason why eps cannot save gradients (?)- but it's way convenient for the renderer.

No, they are not the same, I drew them trying to make a close appearance.

Oh, so you redrew the stars, I understand now
But this method won't work I don't think because I intend to actually use a second file with a transparent background of the stars. They're actually supposed to be png cliparts, so I would think they will probably be used on photos mostly.......gradient fills won't give me the nice blurry edges, am I correct?

[maisieinforestburg]

Ok, with 0.92.2, I tried exporting at 300 dpi to the desktop.  It took about 5 seconds.  I think I might still have a copy of 0.48, I'll try with that.

Yes, with 0.48, it took about 30 seconds to export.  I didn't try exporting directly to an external drive, because there's an easy way around that -- simply save it anywhere and then copy it over to the drive.  That takes Inkscape out of the loop.

Since the problem is not with 0.92.2, the bug that I thought I saw would not be a factor.  So the next thing I would suspect would be your computer's resources.  Do you know how much RAM you have?  I'm pretty sure Inkscape uses RAM for exporting.  If you have an older computer, with....let's say 2 GB RAM or less, that could explain the slowness.  (I have....I think 8 GB of RAM.)

Lazur was just suggesting that if you use gradients instead of blurring, it might speed up the export.  You should be able to get something similar with a gradient.

In any case, if the slowness is attributable to your computer's resources, there's not much we can do, except for suggest ways you can reduce the file size, export faster, etc.

Hi Brynn - I have 4.00 GB installed RAM, and 3.88 GB usable. Is that enough?
I've been trying to export to PNG one particular red star - inkscape just won't respond. Either saving it to desktop or to external drive.
I looked at the green one I managed to export, and the png is only 393 kb. I have attached it here as SVG - it's only 6.28 kb....

I then tried saving it as Cairo PNG and of course it was not rasterized, so that does not do me any good.
I don't know what to do - is there another version of Inkscape in between the newest one that I should try? I would think at this point it is a problem with the inkscape version I have?

[brynn]

Gradients can definitely give you the blurry edges.  It takes a little practice to make it look so much like a blur that you can't tell the difference without looking at the SVG file.  That's what Lazur tried to do in the example SVG file he posted.  I think you could even get closer than he did (he probably was in a hurry).

You can use the same routine that you used before.  You just need to make one red and one green star.  And then you can use the Spray tool to make many more.  In fact, I notice that each of your current stars have a star (blurred 1%), and 2 circles, each blurred around 50% (these are the trouble-makers when you start making a lot of them).  I haven't tried it, but it might be possible to do it with only one circle which is filled with a radial gradient. 

If you want to try with a gradient, here's how I would start:

-- draw a circle
-- fill it with some color
-- click the Radial Gradient button in Fill and Stroke > Fill tab

That automatically creates the 100% opaque to 100% transparent gradient.  Now you can reduce the opacity of the whole circle until it's just right.  If you want to make other adjustments, you need to enable the Gradient tool, add more stops (gradient stops).  Like for example, the red stars look like they have a white center.  It might work just to have white for the center color and red for the outer color.  But you might need another stop to make it look right. 

Sometimes you can double-click on the gradient handle, to add a new stop.  But that does give me trouble sometimes.  So I usually use the control bar, where there is a button to add more stops.


I'm not sure why you're having this difficulty with slow exports and not exporting at all.  That should be enough RAM to handle it.  And I don't see any problems with the files you've submitted.

The only other thing I can think of is if you might have more than say 2 or 3 of these files, which are 1 or 2 mb or larger, all open at the same time.  Or if you're zoomed in a lot on any of them.  Or if you have some other programs open which are also trying to use the same RAM.

It's a well known fact that using a lot of filters in an Inkscape SVG file, can cause performance issues.   I don't think any other version will do any better.  I would try having just one Inkscape file open at a time.  Or if you're already doing that, I would experiment with using gradients instead.

[Moini]

RAM is not an issue here (unless it doesn't export at all). It's CPU that is used for calculating things.

I'd still recommend using 0.92.2 (after removing 0.48 completely!). This is because:
1. You will have less bugs on Windows
2. We will much more easily be able to help you
3. Nobody from the devs will care to fix any bugs in outdated versions, esp. if they are already fixed

When you're using 0.92.2, can you make a screenshot of your export options? And attach info about your CPU and the currently used SVG file?

[maisieinforestburg]

I recently downloaded .92 - it's the one before .92.2, right? I had an issue with the latest one where I downloaded it twice and the box where you pick inches or mm or px in document properties was broken.

Anyway yes, it still froze when I went to export anything with filters applied.....

Thanks for the answers, I appreciate it

[Lazur]

Right now exporting a filtered image -for twenty minutes at least and it's only halfway :/.
Wish there was a better renderer. Like one that could split up the rendering to "sequences" and put temporary bits into a new folder instead of melting the cpu. Another advantage would be to pick up a failed rendering at any point to continue.

[brynn]

I remember the problem you were having with 0.92.2 before, which was strange, and I had never seen it before.  I dont' think we ever finished with troubleshooting.  So I still wonder if it might not have installed correctly.  I think it would be worth a second try, and this time, making sure you download the correct file, and install in the right place.

Or actually you can avoid both of those problems, by getting the 7z version.  You can download and unpack on the Desktop of even in the Download folder, and run it from there.