> (…) since this calculation should be necessary even if no stroke is present.
If there is no stroked object present in the file, there is no need to do the expensive precise bbox calculation where each stroke is converted to path to get the real extent (including miters and markers, and any (non-unifom) transformations in effect).
As mentioned by KK, something is wrong in the workaround currently in effect in trunk (until caching of the bbox values is implemented):
<quote>
The calculation is done too many times. It should only be done for the
rectangle which is moved. I think somewhere there is an uncached call
that should use the geometric bounding box, but uses the visual one
instead.
</quote>
<http://article.gmane.org/gmane.comp.graphics.inkscape.devel/37609>
Alvin Penner wrote:
> not sure if there is any connection to bounding box calculation (…)
Did you read both threads I linked to? IMHO it is the same issue as described by LucaDC in thread. gmane.org/ gmane.comp. graphics. inkscape. devel/37456>
<http://
and confirmed by KK and other developers.
> (…) since this calculation should be necessary even if no stroke is present.
If there is no stroked object present in the file, there is no need to do the expensive precise bbox calculation where each stroke is converted to path to get the real extent (including miters and markers, and any (non-unifom) transformations in effect). article. gmane.org/ gmane.comp. graphics. inkscape. devel/37609>
As mentioned by KK, something is wrong in the workaround currently in effect in trunk (until caching of the bbox values is implemented):
<quote>
The calculation is done too many times. It should only be done for the
rectangle which is moved. I think somewhere there is an uncached call
that should use the geometric bounding box, but uses the visual one
instead.
</quote>
<http://