On 29-12-2011 0:38, Alvin Penner wrote:
Attached is some timing information concerning the bounding boxcalculation, using Inkscape rev 10794. For a test case I used the file spirograph.svg from LP Bug 906952. https://bugs.launchpad.net/inkscape/+bug/906952 The time delay appears to be located almost exclusively in the routine Path::Coalesce (file livarot\PathSimplify.cpp) which is called from the routine item_outline (file splivarot.cpp) which is called from the routine SPShape::sp_shape_bbox (file sp-shape.cpp) which may also optionally be called from the routine sp_group_bbox (file sp-item-group.cpp). On my machine, with this svg file, it takes 5 seconds to calculate the bounding box. The time required depends on the stroke. If I change the stroke from 0.5 px to 10 px, it takes only 1 second, but changing back from 10 px to 0.5 px takes 8 seconds, using the Fill and Stroke editor to modify stroke. In addition, the bounding box is often calculated twice, once if the object is selected, and once again in order to calculate the bbox of the whole image. Even if the complicated object is not selected, the bbox for it will still be calculated, no matter which object is selected or moved, as has been noted previously in this thread. This call appears to come from sp_group_bbox, as far as I can tell. In Inkscape 0.48.2, it appears that the bbox (with stroke) was calculated using the option SPItem::APPROXIMATE_BBOX, which no longer exists. This option compensated for stroke by adding half the stroke to the bbox at each side, but did not take into account the style of endpoints. It does not respond to any changes in EndCap style in the Fill and Stroke editor (but it is faaast). It appears that we need a compromise of sorts: if the path touches the (geometric) bbox tangentially, then we can ignore endcap style and use the half stroke width as in APPROXIMATE_BBOX (which is very fast), and if the path endpoint is touching the (geometric) bbox then we need to compensate for endcap style as is currently being done.
Keep in mind that there are cases where we really do not need to know the bbox very accurately, so it would be good to bring the approx bbox calculation back.
Ciao, Johan