On 29-12-2011 0:38, Alvin Penner wrote:
> Attached is some timing information concerning the bounding box
> calculation, using Inkscape rev 10794. For a test case I used the file
> spirograph.svg from LP 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
> 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