Re: Bounding Box Calculation

On Monday, October 6, 2003, at 09:44  AM, Dean Jackson wrote:
>> "The bounding box is computed exclusive of any values for clipping,
>> masking, filter effects, opacity and stroke-width."
>> 	- http://www.w3.org/TR/SVG11/coords.html#ObjectBoundingBox
>
> I think this covers the overflow style as well.

I agree that it is logical to extrapolate the above to implicitly cover 
'overview' as well.

The only reason I wrote the preamble was to say "I note that overview 
isn't explicitly mentioned, so if I'm making a fool of myself, at least 
I'm pointing out an area where possibly my confusion could be 
attributed to, making it less of my fault that I'm acting the fool" :)



> Maybe I misunderstood, but do you suggest that the bounding
> box should be clipped by the viewport? ie. that things that
> are off the side of the canvas should have a empty bounding
> box?

Let me offer a few cases, how I believe each should behave, and why:


<svg viewbox="0 0 100 100" style="overflow:visible">
	<rect x="-100" y="-100" width="300" height="300"/>
</svg>

If I ask for the BBox of the SVG or the rect in the above, I expect to 
get the bounds of the rect. (-100,-100 to 200,200). I expect this as a 
developer because it is what is drawn.



<svg viewbox="0 0 100 100" style="overflow:hidden">
	<rect x="-100" y="-100" width="300" height="300"/>
</svg>

Now that the overflow is hidden, if I ask for the BBox of the SVG 
above, I expect to get 0,0 to 100,100. This is all that is drawn, no 
matter what vector points may lie outside it. You asked for a use case. 
Slightly contrived, let's say that I'm writing a simulation with 
collision detection. This SVG element will never collide with anything 
outside its viewBox. Or perhaps I'm doing an optimization algorithm 
where it's important to detect the minimal areas affected by a change. 
Or (okay, here's a better one) let's say that I'm using BBox to 
determine if two objects overlap at all before doing an intersection 
routine on them. If they're clipped and hidden by the viewbox, I (as 
the user invoking the intersection) wouldn't expect the intersection to 
include bits that are hidden, and so I (as the developer) would want 
the real visual bounds, as clipped by the overflow.

[The real case is that I was hoping to use the BBox of the SVG to help 
determine viewBox scaling for transforming screen space to object 
space, but I understand that other techniques can be used for this.]

If I ask for the BBox of the rect above, I'm not sure which I expect. I 
think, given the collision detection case, I would still expect the 0,0 
100,100 BBox. SVG is primarily about display, and to the user this 
overflow:hidden rect is almost identical to one with drawn along the 
edge of the viewBox.

Perhaps I can turn the tables: can you explain to me a case where the 
current behavior is useful to the end developer? You say:


> Also, remember that you can already work this out using script, but 
> removing the functionality would not provide the inverse (ie. if we 
> made the change you suggest you wouldn't be able to find the real bbox 
> of things).

Er, sure you would, right? 'Just' loop through all the descendants of 
the object and do some min/max calculations on the points, right? :p 
[OK, maybe it would be a pain with Bezier lines where a curved section 
would overlap a boundary.]

My point is that most anything an be worked out using (enough) script, 
it's a matter of speed and convenience for the developer. I think the 
main issue here is that I can think of cases where I want BBox to not 
included stuff that is clipped or hidden, but not the reverse.


> It isn't in the list of things that will be added to
> the next SVG 1.2 draft, so I'll have to check more carefully.

Thanks.



In conclusion, almost all the cases I can think of where I want to use 
BBox are for either:
a) handling screenspace<->object space transformations, or
b) collision/intersection detection.

I hear that (a) is handled far better in 1.2, and so I'm happy to 
ignore that.

Further, (b) is only moderately useful, given that BBox uses rects, and 
there are already slightly better-suited functions for this. If these 
intersection bits could be fixed per my suggestion:
http://lists.w3.org/Archives/Public/www-svg/2003Oct/0001.html
then I'd be a happy camper and really be happy to drop this issue for 
all practical purposes.

(Idealistically I still feel that there ought to be a bounding box 
calculation which includes strokes, and excludes clipped and 
overflow:hidden bits, but would also be happy if this were a separate 
method rather than fighting to change the existing one's logic.)


--
A: Because this just doesn't make any sense.

Countless people have asked:
 > Q: Why don't you like replies at the top of messages?

Received on Monday, 6 October 2003 12:33:49 UTC