Re: Geometric vs rasterized bounding boxes

On Oct 30, 2013, at 9:37 PM, Philip Rogers <pdr@google.com<mailto:pdr@google.com>> wrote:

www-svg,

Current implementations return the geometric (i.e., without antialiasing) bounding boxes for getBBox() and getStrokeBBox(). What do you think about an API, probably an optional dictionary argument for getBBox, for accessing the rasterized bounding box as well? Alternatively, "getAABBox" :)

In implementing getStrokeBBox() for Blink I found it difficult to compute the rasterized bounding box for positioning a div exactly over a rendered SVG rect. Hairline curves in Blink have special rules for aesthetics that give different antialising values which can lead to surprising differences between the rasterized and geometric bounding boxes. For device scale factors that aren't 1, the rasterized bounding box could have non-integer components.

For example:
<rect x='100' y='100' width='100' height='100' stroke-width='0.2' />
geometric stroke bounds: (x=99.8, y=99.8, width=100.4, height=100.4)
rasterized stroke bounds: (x=99, y=99, width=102, height=102)

One potential issue is whether this requires a readback on fully-accelerated backends. I would love to hear feedback on whether this can be efficiently implemented in IE.

For reference, the relevant spec section:
https://svgwg.org/svg2-draft/single-page.html#types-__svg__SVGGraphicsElement__getBBox

I can not say if or how IE can implement it :). Rather then concentrating if one specific browser can implement it, we should look at the use case but some more questions at the beginning. You suggest to get the “rasterized” bounding box of the stroke bounding box.

The problem that I have with “rasterized” bounding box is that this would be highly dependent of the current soon level, transforms, viewport scales, user zoom, device pixel ratio and the use AA algorithm which may depend on several previous steps as well.

Lets say it is not a problem, but needs to be carefully taken into account when calculating this box. You mention stroke bounding box as a use case. Does it mean that normal bounding box (fill area) is less of a problem and actually returns the right value from the rendered result and the geometric result? Would be surprising I guess.

Greetings,
Dirk




Philip