On Tue, Sep 4, 2012 at 4:59 AM, Auguste Pop <auguste@...155...> wrote:
I think inkscape's problem is it tries to render the whole image instead of only the visible part. That's why when we zoom in, the render process becomes increasingly slow.
I don't believe that is the case, but as Jasper mentioned, it does have to render more than is visible on screen.
Consider two objects right next to each other, both with Gaussian blur applied. If you zoom in on one of them you would expect to see the blur of the other object creeping in at the edge of the window, and mingling with the blur around the zoomed object. So Inkscape has to render at least part of the off-screen object, complete with blur, so that it can accurately display it bleeding into the window.
The real problem is the number of filtered pixels to be calculated. A box that's 100x100 pixels at one zoom level will be 50x50 or 500x500 at others. Because filters are (generally) bitmap operations that apply to each pixel in the filtered area (and beyond), more pixels means more calculations, means slower redraws.
Try this experiment:
1) Create a blurred object then zoom in far enough for the redraw to become noticeably slow. 2) Switch to outline view mode and full-screen Inkscape (F11). 3) Now switch back to normal view mode and time how long it takes to redraw. 4) Switch to outline mode again, and resize your window to be significantly smaller. 5) Switch back to normal view mode, and time how long it takes to redraw.
Note that we haven't changed the zoom at any point, so if Inkscape is drawing the whole image, the timings from (3) and (5) should be similar. In my tests they're not, with (5) being significantly faster. That's why I don't use Inkscape full-screen or even maximised, but prefer to work within a smaller window and use floating tool palettes rather than docked ones.
Mark