Dear list,
this is my first contact to the inkscape developer community and I hope my messages is not received as being overly critical or even offending as I'm clearly talking about things I do not fully understand. You're all doing a great job on Inkscape and I l-o-v-e the upcoming 0.49 release!
It is no secret that Inkscape suffers some performance issues when editing or just viewing complex svg files, especially at high zoom levels. Particularly there is a noticable lag between a user action (e.g. zooming in) and the start of the rendering process.
I'm not an experienced c++ programmer nor do I know much about how Inkscape works internally but I crawled through the code, following the chain of actions Inkscape does, when its processing its user actions and it turned out that commenting out the following lines instantly removes the bespoken delay and thus greatly accelerates the responsiveness of the program for complex drawings:
in drawing-item.cpp, line 586 - 589:
:572 if (_cached) { if (_cache) { _cache->prepare(); #ifdef WITH_CSSBLEND set_cairo_blend_operator( ct, _blend_mode ); #endif _cache->paintFromCache(ct, carea); if (!carea) return RENDER_OK; } else { // There is no cache. This could be because caching of this item // was just turned on after the last update phase, or because // we were previously outside of the canvas. Geom::OptIntRect cl = _drawing.cacheLimit(); cl.intersectWith(_drawbox); /* if (cl) { _cache = new DrawingCache(*cl); } */ } } else { // if our caching was turned off after the last update, it was already // deleted in setCached() :593 }
I don't know much about Inkscapes caching mechanisms but clearly a cache that slows down a program instead of accelerating it is broken. Furthermore this else-statement should be a rather rare exception to be called but the program behaviour indicates its called not only for every object but also every time the canvas is updated, which might indicate a more complicated issue..
I am fully aware that just commenting this out is not a solution to the problem but maybe somebody more experienced could have a look at the functions involved and come up with a more sophisticated solution?
The second suggestion I wanted to make is more a design decision I'm afraid. It is about Inkscape interrupting the redraw process (see sp-canvas.cpp, around line 1967)
At the moment the redraw is aborted if its not done in less than 1 microsecond, which, at least on my system, almost never happens unless I pan very slowly. The result are very ugly artefacts on the edge of the screen when the user pans/scrolls the canvas (see this screenshot for clarification: http://www.gorilla-computing.de/misc/inkscape_screenshot.jpg).
Has ever been considered to increase that limit so Inkscape can actually finish the redraw more often? I experimented around a bit and a value of 100ms seems to do the job just fine - especially with the cache lag gone. And it should still be low enough to process different user input when needed. If it is not possible to hardcode that limit to a sensible value, maybe one could make it a slider in the options->render menu?
Thanks for your considerations!
Best, Paul