On Fri, Sep 16, 2005 at 04:46:36PM -0400, mental@... wrote:
> Quoting bulia byak <buliabyak@...>:
> > 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.)