Inkscape performance
Hey all,
So, with the last couple files I've worked on (my last hitting 23.5megs... note that I abuse clones ;)), Inkscape's performance seems to have tanked.
Is this due to the nature of a "bloated" (not really bloated, but I used the term because it's human readable) format or a parsing issue or something else? I'm just curious if there's anything that could possibly be done to improve the performance.
I know that I had files this complex in AI, and it could hang when the files got huge and I copied/pasted objects around. But it's even painful with stuff like pulling up the fill & stroke dialog for the first time in a session with one of these complex docs. It will take like 3-5 mins to unfreeze and show the dialog.
Just figured I would ask.
-Josh
On 8/8/07, Joshua A. Andler <joshua@...533...> wrote:
Is this due to the nature of a "bloated" (not really bloated, but I used the term because it's human readable) format or a parsing issue or something else? I'm just curious if there's anything that could possibly be done to improve the performance.
You identified the problem yourself - it's the slowness of the renderer and the incredible memory hogging by livarot. While by itself it's simply slow, its memory consumption sometimes makes it deadly slow, up to and including frozen.
Try viewing the same page in outline mode. Note the memory difference. That's, more or less, what you will get in regular mode too once it's switched to cairo - at least for flat colors. It will likely be slower for gradients (don't know by how much), and it will be about as slow as now for blur because we still do blur ourselves. But still this should give you an idea.
Of course there are other bottlenecks besides the renderer too, but it makes little sense to search for them now because they're unlikely to make big difference anyway.
bulia byak wrote:
On 8/8/07, Joshua A. Andler <joshua@...533...> wrote:
Is this due to the nature of a "bloated" (not really bloated, but I used the term because it's human readable) format or a parsing issue or something else? I'm just curious if there's anything that could possibly be done to improve the performance.
You identified the problem yourself - it's the slowness of the renderer and the incredible memory hogging by livarot. While by itself it's simply slow, its memory consumption sometimes makes it deadly slow, up to and including frozen.
Try viewing the same page in outline mode. Note the memory difference. That's, more or less, what you will get in regular mode too once it's switched to cairo - at least for flat colors. It will likely be slower for gradients (don't know by how much), and it will be about as slow as now for blur because we still do blur ourselves. But still this should give you an idea.
Thank you for the response. :)
I will do a little profiling myself tonight seeing memory consumption on that last big file I did. Is there a command line option to open in outline mode? Or am I going to be opening the file, then switching to outline mode, saving, closing inkscape and reopening with that file (to ensure memory is cleaned out)? I'll be interested to see the difference.
As for livarot in general, we use it both for rendering and for our "math" in relation to manipulating paths, correct? When we have our renderer switched as well as have lib2geom take over for working with paths, will livarot still be used for anything?
-Josh
P.S. Roughen in the Tweak tool is beyond incredibly awesome! :)
On 8/9/07, Joshua A. Andler <joshua@...533...> wrote:
I will do a little profiling myself tonight seeing memory consumption on that last big file I did. Is there a command line option to open in outline mode?
A pref setting: http://wiki.inkscape.org/wiki/index.php/ReleaseNotes045#Outline_mode, last item
As for livarot in general, we use it both for rendering and for our "math" in relation to manipulating paths, correct?
Yes.
When we have our renderer switched as well as have lib2geom take over for working with paths, will livarot still be used for anything?
Hopefully nothing :)
On Thu, 2007-08-09 at 18:22 -0300, bulia byak wrote:
Try viewing the same page in outline mode. Note the memory difference. That's, more or less, what you will get in regular mode too once it's switched to cairo - at least for flat colors. It will likely be slower for gradients (don't know by how much), and it will be about as slow as now for blur because we still do blur ourselves. But still this should give you an idea.
If it proves advantageous, we should still be able to use our current gradient renderer with cairo. IIRC, it has some additional nicities over cairo's, including dithering to minimize the appearance of banding.
-mental
MenTaLguY wrote:
On Thu, 2007-08-09 at 18:22 -0300, bulia byak wrote:
Try viewing the same page in outline mode. Note the memory difference. That's, more or less, what you will get in regular mode too once it's switched to cairo - at least for flat colors. It will likely be slower for gradients (don't know by how much), and it will be about as slow as now for blur because we still do blur ourselves. But still this should give you an idea.
If it proves advantageous, we should still be able to use our current gradient renderer with cairo. IIRC, it has some additional nicities over cairo's, including dithering to minimize the appearance of banding.
Actually I don't think that's the case. I looked into gradient rendering a while ago (and double-checked just now) and I don't see anything that (at least obviously) takes care of dithering. I in fact experimented with adding dithering. And I believe I concluded that it would eventually not be worth it, mostly because of degraded performance and enlarged file size when exporting. It would probably be better to make it possible to render to 16 bits per pixel per color (and optionally dither to 8 bits afterwards), also because I seem to remember that images could get a bit noisy when semi-transparent layers of dithered gradients were composited (but I'm not 100% sure about that, it was a while ago).
participants (4)
-
bulia byak -
Jasper van de Gronde -
Joshua A. Andler -
MenTaLguY