![](https://secure.gravatar.com/avatar/014b988254e77ad61312267eb1d2d696.jpg?s=120&d=mm&r=g)
2011/8/30 ~suv <suv-sf@...58...>:
On 29/8/11 20:18, Krzysztof Kosiński wrote:
W dniu 29 sierpnia 2011 18:23 użytkownik ~suv <suv-sf@...58...> napisał:
- The new bounding box calculations seem to be very slow when working
on files with either large stroked paths or groups containing a decent number of stroked objects, even with optimized builds ('-O3'). This affects basic operations: opening the file, selecting/de-selecting large objects or groups, zooming, dragging with the select tool (groups), switching from node tool back to the select tool (large paths) etc.
Looks like the slowest part is computing the stroke bbox and the slowdown is caused by computing the offset of the entire path using livarot and then computing the bounding box of that. The result is not stored anywhere for reuse. To speed up this operation we can do two things:
- store the result in SPItem and invalidate it on updates so it is
recomputed only when needed 2. use a better algorithm of computing the bounding box that does not compute the offset of an entire path
I don't know how hard 2 will be to implement so for now I can restore the legacy behavior of always expanding the bbox by half of the stroke width.
The downside of reverting to the legacy behavior is that its visual bbox does not match the strokes of non-uniformly transformed shapes, clones or paths within groups which have been stretched or skewed (a major change in the new renderer, fixing long-standing bug #165715):
Bug #805793 "Visual bounding box no longer matches transformed stroke" https://bugs.launchpad.net/inkscape/+bug/805793
This affects bbox snapping and all 'Align&Distribute' operations (which for now do not adhere to the bbox mode as chosen by the user and _always_ use the visual bbox), as well as other features relying on the old legacy visual bbox: e.g. Rows&Columns (always visual bbox) and Tiled clones (with the legacy code, tiled clones show inverted behavior here: the calculation for the tiled clones appears to use the geometric bbox when visual bbox is set in the preferences and vice versa (bug #553912); with current trunk it appears to respect the bbox setting correctly).
On the other hand the current performance with stroked paths is quickly slowing down any work (at least on this rather slow 32bit system (2.4 GHz Intel C2D) - I haven't heard much feedback from others about it yet).
It's painful on my i7... so I assume it's not multithreaded. Either way, it would still be super painful.
Cheers, Josh