2011/10/10 Diederik van Lierop <mail@...1689...>:
On 10/10/2011 02:21 PM, LucaDC wrote:
Krzysztof Kosiński wrote:
Currently the visual bbox calculation is done in a very inefficient way using livarot. It could potentially be improved by using cairo_stroke_extents instead.
Thanks for all the replies/explanations. Ok, I'll positively wait for an improvement on this side. But maybe it's worth saying that I always use geometrical bounding boxes, so I can't understand why all these useless calculations on strokes are performed anyway (if I correctly understand).
What I believe that has happened is that someone introduced the geometric bounding box vs. visual bounding box option at some point in time, for a specific purpose. E.g. for allowing the user to specify dimensions of the geometric bounding box, whereas before Inkscape only had the visual bounding box. That's likely why it's a sub-option for the selector tool, and not a general option. Then, over time, more and more code was implemented that reads that parameter for other purposes, up to the point where we are now: some codes uses the visual vs. geom. bounding box parameter, whereas other code simply always uses the visual bounding box. That's probably related to what you're seeing and not what you weren't expecting.
The problem is a bit deeper. There was a lot of code that used the "approximate" bounding box, which is not well defined, but roughly corresponds to the visual bounding box and is easy to calculate. I changed most code that used approximate bbox (which was the default) to use the visual bbox and removed the default value from methods that take a bounding box type, to force people to specify which kind of box they mean. As I worked through the code it became apparent that a lot of it is wrong and should use the geometric box, but this could cause regressions.
Regards, Krzysztof