W3C home > Mailing lists > Public > www-svg@w3.org > October 2003

Re: Bounding Box Calculation

From: Dean Jackson <dean@w3.org>
Date: Tue, 7 Oct 2003 15:11:53 +1000
To: Gavin Kistner <gavin@refinery.com>
Cc: www-svg@w3.org, svg-developers@yahoogroups.com
Message-ID: <20031007051153.GB25292@grorg.org>

On Mon 06 Oct 2003, Gavin Kistner wrote:

> 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" :)

You're right, it should be mentioned.

> >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.

Speaking as a developer myself, I expect (-100, -100 to 200, 200)
because that is the bounding box of the rectangle. I don't
care what is drawn (nor where it 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. 

Like I said above, that is definitely not what I want. I would
also expect that the vast majority of people don't want that
either. I'm not saying that *you* don't want it :)

Here are a few reasons:

- Firstly, the bounding box of objects is relative to their
  user space. That is, if you are buried deep within nested
  transformations then getting the bounding box clipped by
  the viewport doesn't make sense. In most cases, the 

- Secondly, SVG followed the conventions in this regard.
  Java2D, Quartz, etc are the same.

- Thirdly, if we changed the bounding box to be clipped by
  the viewport, then we'd have to make the bounding box in
  viewport coordinates. This would mean that lots of simple
  cases would act weird. For example:

  <svg>
     <g transform="rotate(45)">
       <rect x="100" y="100" width="80" height="80"/>
       <rect x="200" y="100" width="80" height="80"/>
     </g>
  </svg>

  In your system, the bounding boxes of the two rectangles would
  intersect, yet they clearly do not touch each other.

- Lastly, and probably most importantly, if we did automatically
  clip the bounding box to the viewport, then how would you
  get the bounding box of objects that are not drawn? This is
  a one way filter. I guess we could add new methods, but I'm
  not sure it is useful.

To solve your problem, why don't you just write a function to
intersect the object bounding box with the display area? You're
only talking about 8 coordinates so it isn't so resource intensive.
The SVG DOM gives you everything you need to do this.


> 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. 

Just because you can't see it doesn't mean it didn't happen
(if a tree falls in the forest....). If you want to program 
your simulation to not detect offscreen collision then write
an isOnScreen() test.

> Or perhaps I'm doing an optimization algorithm 
> where it's important to detect the minimal areas affected by a change. 

I'm not sure exactly what you mean here, but I think that again
you could write a function to do this.

> 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.

Really? As a developer I'd want the real intersection. What happens
if the user pans? Do you need to do the (complex) intersection 
again?

> [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.]

That's right. I don't mean to say that your use cases are not
real - I know you want to do this from the fact that you posted
a long and detailed request. However, I think that you can
achieve everything you want already today, and it is the better
way to do it.

> 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.

SVG is both a grammar for describing vector objects and an API
for graphics. The display really is only one part of the picture.

And, as Doug says is a mearby message, if you do everything in
screen coordinates then you run a greater risk of errors.

> 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:

Hopefully some of the things I've said above answer this
question. The overriding factor is that I want the bounding
box to be as precise as possible. If I introduce errors (or
filters) early, then it loses value for me.

Suppose I'm using SVG without any display. I simply want to
merge two SVG files to find all overlapping objects, such
as all roads that intersect rivers. I don't care about the display
yet -- I'm just outputting to a file.

> >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.

I doubt you'd really suffer much of a performance or coding
penalty here. In fact, as I said above, you'd probably find you
have to do a lot more work to make up for the inaccurate results.

> >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.

For this I meant purely the ability to get the
bounding box including the stroke or filter. Again, I'm
not sure it was accepted.

> 
> 
> 
> 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.

It is, and will help with the use cases you mention.

> 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.

There is discussion of intersection/collision detection
in the group for SVG 1.2. We're looking at the community
input.

> (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.)

If it is included it will definitely be a different method.

If we changed the existing method, I'm sure there would
be a huge amount of broken content.

Dean
Received on Tuesday, 7 October 2003 01:11:58 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:25 GMT