trunk: visual bbox of clipped objects is inaccurate

Also reproduced with stable 0.48.5.

Not reproduced with r13491 based on the provided steps (random closed shapes). IIRC this bug depends on the geometry of clip and clipped object, and only occurs under certain circumstances (not related to using a clone as clip).

Attached example shows incorrect visual bbox with a concave polygon as clip-path (top row center, middle row right, bottom row center) - reproduced with stable 0.48.5 and current trunk r13491on OS X 10.7.5.

@LiamW - please verify that the test case in the attached file matches what you reported.

Screenshot with 0.48.5 showing sel cues of visual bbox of the clipped objects (visualization layers turned off).

Two examples I had saved earlier (to be investigated) with concave objects clipped by convex objects - same issue?

(to test the effect: select object on the left, switch to node tool (enable path outline, clip-path editing), select all nodes of the clip-path and drag it around while watching how the bbox updates.)

I agree that the bbox that is shown for clipped objects is often unexpectedly large, noticeably larger than the clipped object itself. However, I think it is this way by design, not by accident. The point is that the bbox of a clipped object is defined to be the intersection of two separate bboxes which are both defined to be rectangles. The clipped object, on the other hand, is the intersection of two irregular objects, not rectangles. Since the original bboxes of the two objects were "larger" than their objects, therefore their intersections will be "larger" as well.
    A little demo in the attached figure. Two rectangles and two circles drawn side by side exactly parallel. On the left side the width of the circle is 160 pixels. The vertical overlap between circle and square is exactly 30 pixels. On the right side is the clipped object. If you click on it, you get a bbox of width 160 and height 30 as expected, which is significantly larger than the clipped object.