The purpose of the Path::Coalesce(double tresh) routine appears to be to detect whether successive segments on a multi-segmented path are smooth continuations of each other, and to merge them in that case. To do this a numerical tolerance is used to determine what is 'smooth', and the tolerance is based on the stroke width in this particular case. One can increase the likelihood of detecting a smooth join by increasing the stroke width, which is why the execution time depends (quite strongly) on stroke width. However, when calculating a bbox, there does not appear to be any practical reason for using this routine. The bbox will clearly not be affected by the merge of two segments if they are smooth, and the only obvious benefit is faster execution speed, which in this case has not been achieved. If I comment out the call to Path::Coalesce in line 784 of splivarot.cpp, then the execution speed returns back to a value that is comparable to Inkscape 0.48.2 as far as I can tell, while the bbox is unaffected by this change. The visual bbox obtained in this way contains more information than the bbox in Inkscape 0.48.2, since it responds to changes in endcap style and join style. Any objections if I comment out this line of code?