On 10/15/06, Jasper van de Gronde <th.v.d.gronde@...528...> wrote:
This seems odd, why would you ever need a pixel buffer *much* larger than the visible canvas? Is it because the entire object has to be rendered? If so, can something be done about that? (might also speed things up)
Not ALL of the object, of course. But to correctly render blur, you must have your canvas enlarged by the blur radius on all sides, because these margins will affect what you see. And the blur radius at high zooms can easily run into thousands of screen pixels.
For rendering purposes this seems okay, but is this also enabled when exporting? Personally I wouldn't mind waiting a long time when exporting (not that I am likely to actually have documents that would approach this limit, but still), and I've got 1GB of memory, so I would rather see Inkscape just try to do the best it can.
Yes, that makes sense. I'll remove the 100Mb pre-allocation cutoff for command line operations (but not for GUI export, because the entire point of that cutoff is to prevent GUI from being bogged down).
And, assuming it's not possible to remedy the situation, when rendering it might be a good idea to create some kind of visual indication of having skipped some part (so the user isn't left wondering what the hell happened and possibly even tries to apply an effect twice for example).
Right now you get a warning on the console when this happens. I know this is not very Windows-friendly but I'd be reluctant to provide some sort of GUI indication for what is essentially an exceptional condition.