Go for it... if it breaks anything we can just revert the commit.


On Jan 1, 2012 4:02 PM, "Alvin Penner" <penner@...1856...> wrote:

   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
   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?

View this message in context: http://old.nabble.com/Inkscape-slowing-down-tp32606652p33063833.html
Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
Inkscape-devel mailing list