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.