Hi,
I believe there is a problem with the way bounding boxes are calculated. At the moment the calculation assumes that lines have a
Round< join and cap style if the stroke is visible. This means, for
example, that the bounding box of a 30-60-90 degree triangle does not preserve the proportions of the triangle and that a triangle with a Miter join style extends past the bounding box. It also means that a non-horizontal or vertical line with a Square cap extends outside the bounding box and that a line with a Butt cap doesn't reach the bounding box. I can't see any advantage to this particular definition.
A better choice for defining the bounding box would be to use the entire visible area covered by an object.
Advantage: More intuitive and probably what most people would expect.
Disadvantage: More CPU intensive? May not be what is wanted for lines with markers - could ignore.
There may be occasions where a different definition could be advantageous such as defining a bounding box assuming a Miter join style or using only the nodes (both preserve the proportions of regular objects). Perhaps these could be added as per object options.
Tav
On Fri, Sep 16, 2005 at 11:56:58AM +0200, Stephen Schrenk wrote:
I believe there is a problem with the way bounding boxes are calculated. At the moment the calculation assumes that lines have a
Round< join and cap style if the stroke is visible.
Yes. This is a long-outstanding bug.
Disadvantage: More CPU intensive?
The easiest implementation of correct calculation is CPU expensive.
It may be possible to do a correct calculation without too much more CPU cost than at present, but just requires a bit more programming work.
Re expensive: bounding box calculations already take quite a bit of time in inkscape, which makes me think that they should be cached.
One other approach I thought of would be to change existing bbox calls to specify whether they want to err towards too small, too large, or correct even if it uses lots of CPU.
pjrm.
Quoting Peter Moulder <Peter.Moulder@...38...>:
On Fri, Sep 16, 2005 at 11:56:58AM +0200, Stephen Schrenk wrote:
I believe there is a problem with the way bounding boxes are calculated. At the moment the calculation assumes that lines
have a
Round< join and cap style if the stroke is visible.
Yes. This is a long-outstanding bug.
When you're using miter joins, the necessary padding to the path bounding box will be the stroke width * the miter limit, instead of the stroke width.
That's the only adjustment required to fix the bug.
-mental
On 9/16/05, mental@...3... <mental@...3...> wrote:
When you're using miter joins, the necessary padding to the path bounding box will be the stroke width * the miter limit, instead of the stroke width.
That's the only adjustment required to fix the bug.
No. This will give much too big bbox inflation than necessary in the big majority of cases. It's extremely rare that the real object bbox srtetches to the entire stroke width * the miter limit. So compared to that, the current method (just adding stroke width) gives correct results in a much bigger % of cases, and when it's wrong, its error is much lower.
The only advantage of your method is that it always gives a _guaranteed_ inclusion (i.e. upper limit for the bbox), but I don't think we're interested in that.
Quoting bulia byak <buliabyak@...400...>:
The only advantage of your method is that it always gives a _guaranteed_ inclusion (i.e. upper limit for the bbox), but I don't think we're interested in that.
This would be specifically for computing update regions -- there, we certainly are.
Without guaranteed inclusion, we get "trails" and unpleasant rendering artifacts, which is what the bug was about.
My own feeling is that bounding boxes for other purposes -- for example tile layout -- shouldn't include the stroke width at all. But I wouldn't insist on it.
-mental
On 9/16/05, mental@...3... <mental@...3...> wrote:
Quoting bulia byak <buliabyak@...400...>:
The only advantage of your method is that it always gives a _guaranteed_ inclusion (i.e. upper limit for the bbox), but I don't think we're interested in that.
This would be specifically for computing update regions -- there, we certainly are.
Ah, that makes sense then. But anyway, we also need the correct bboxes calculation for presenting to the user and for most other purposes.
And by the way, your method will still need to be tweaked to account for markers and for gaussian blur (when we have it).
My own feeling is that bounding boxes for other purposes -- for example tile layout -- shouldn't include the stroke width at all. But I wouldn't insist on it.
No, that's the way it was in Sodipodi and early Inkscape versions, and we got many bug reports on that, until Fred coded the simplistic "add the stroke width" thing we still use today.
Quoting bulia byak <buliabyak@...400...>:
And by the way, your method will still need to be tweaked to account for markers and for gaussian blur (when we have it).
We're okay for markers, since (within the canvas, at least), they're child objects who contribute to their parents' bounding box.
Filter effects are a separate issue -- the output of some filters (e.g. feFlood, feImage, feTurbulence, etc...) is not related to the origin shape at all. So it's probably best to use larger of either the normal bbox or the filter effects region[1].
-mental
[1] http://www.w3.org/TR/SVG11/filters.html#FilterEffectsRegion
If otherwise unspecified, the filter effects region is going to be the object's bounding box, without stroke, plus 10% padding on all sides.
On Fri, Sep 16, 2005 at 05:56:24PM -0400, mental@...3... wrote:
So it's probably best to use larger of either the normal bbox or the filter effects region[1].
To be precise, I assume mental is proposing to include the filter effects region in the bbox calculation rather than literally just choosing the larger of the two.
pjrm.
On Fri, Sep 16, 2005 at 05:55:30PM -0300, bulia byak wrote:
My own feeling is that bounding boxes for other purposes -- for example tile layout -- shouldn't include the stroke width at all. But I wouldn't insist on it.
No, that's the way it was in Sodipodi and early Inkscape versions, and we got many bug reports on that, until Fred coded the simplistic "add the stroke width" thing we still use today.
I thought mental was referring to clone tiling, which wasn't in sodipodi. Mental?
pjrm.
On Sat, 2005-09-17 at 10:54 +1000, Peter Moulder wrote:
On Fri, Sep 16, 2005 at 05:55:30PM -0300, bulia byak wrote:
I thought mental was referring to clone tiling, which wasn't in sodipodi. Mental?
I was thinking in general for the UI, actually. Sometimes I want to be able to place shapes precisely adjoining one another (without considering stroke with).
However, I can generally turn off strokes to do that, and it's rare.
It is apparent that most users care about the "visual" bounds, which includes the stroke thickness.
-mental
On Fri, Sep 16, 2005 at 04:46:36PM -0400, mental@...3... wrote:
Quoting bulia byak <buliabyak@...400...>:
The only advantage of [the miter-limit] method is that it always gives a _guaranteed_ inclusion (i.e. upper limit for the bbox), but I don't think we're interested in that.
This would be specifically for computing update regions -- there, we certainly are.
Another case where we want inclusion is for export selection to bitmap; though this is an example where slow-but-correct would be better still if we were to implement that option.
(The slow, correct [*1], easy-to-implement algorithm I'm thinking of is to use the existing stroke-to-path code and take the bounding box of that. (Plus something for filters when we have them.) There are some optimizations available given that we don't need any points inside the bounding box, but I suggest starting with something this simple: e.g. so that it can be used as a point of comparison for regression testing of the optimized version.
[*1]: Or as correct as the stroke-to-path code is, anyway. I forget whether it has any known bugs, e.g. with markers or dashes.)
pjrm.
On 9/16/05, Peter Moulder <Peter.Moulder@...38...> wrote:
[*1]: Or as correct as the stroke-to-path code is, anyway. I forget whether it has any known bugs, e.g. with markers or dashes.)
Yes, it fails on both markers and dashes:
http://sourceforge.net/tracker/index.php?func=detail&aid=933482&grou...
and sometimes also on metered joins:
http://sourceforge.net/tracker/index.php?func=detail&aid=936771&grou...
It also differs from the renderer in treating transformed strokes:
http://sourceforge.net/tracker/index.php?func=detail&aid=962492&grou...
On Fri, 2005-09-16 at 23:12 -0300, bulia byak wrote:
On 9/16/05, Peter Moulder <Peter.Moulder@...38...> wrote:
[*1]: Or as correct as the stroke-to-path code is, anyway. I forget whether it has any known bugs, e.g. with markers or dashes.)
Yes, it fails on both markers and dashes:
http://sourceforge.net/tracker/index.php?func=detail&aid=933482&grou...
and sometimes also on metered joins:
http://sourceforge.net/tracker/index.php?func=detail&aid=936771&grou...
It also differs from the renderer in treating transformed strokes:
http://sourceforge.net/tracker/index.php?func=detail&aid=962492&grou...
That surprises me a bit. Both the stroke rendering and stroke-to-path are implemented by livarot currently -- do you mean that it has two entirely different stroking implementations?
Actually, I guess that wouldn't surprise me...
-mental
On 9/17/05, MenTaLguY <mental@...3...> wrote:
That surprises me a bit. Both the stroke rendering and stroke-to-path are implemented by livarot currently -- do you mean that it has two entirely different stroking implementations?
In a way, it's inevitable. If stroke-to-path used the same code as the renderer, it would produce way too many nodes with straight line segments between them. So it has to simplify the result, at least, which always results in some deviations.
participants (5)
-
unknown＠example.com -
bulia byak -
MenTaLguY -
Peter Moulder -
Stephen Schrenk