You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by G33K <g9...@fastmail.net> on 2009/05/19 14:07:33 UTC
Accuracy of bounding boxes for transformed shapes
Hi, I've got an issue with the bounding boxes.
Correct me if I'm wrong, but it seems that the Batik bounds returned by
getBounds() and getTransformedBounds() are calculated with regard to
efficiency, and are therefore not always correct.
When I display a bounding box for a rotated circle (which should have
the same bounds no matter how it is rotated) the box changes as if the
original square bounding box was part of the shape, e.g. the bounds get
larger as you approach 45 degrees. That would mean that the bbox is in
fact a maximum bbox. The exact bounds can't be larger (so it's safe to
clip), but they could be smaller.
Is there another method that would yield the accurate bounds of
transformed shapes? My idea would be as follows:
As the bounds of an untransformed path are 100% accurate, I'd like to
write a recursive function that calculates a bounding box by gathering
all the inner shapes of a node, transforming their GeneralPaths, and
then adding all the Rectangles together. That's inefficient, but
probably accurate.
Does something like this exist already? Or am I maybe missing something
important here?
Many thanks and best regards,
Gerrit
--
http://www.fastmail.fm - Access your email from home and the web
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Accuracy of bounding boxes for transformed shapes
Posted by G33K <g9...@fastmail.net>.
> > When I display a bounding box for a rotated circle (which should have
> > the same bounds no matter how it is rotated) the box changes as if the
> > original square bounding box was part of the shape, e.g. the bounds get
> > larger as you approach 45 degrees. That would mean that the bbox is in
> > fact a maximum bbox. The exact bounds can't be larger (so it's safe to
> > clip), but they could be smaller.
>
> Wow, I'd say this is pretty weird. Please provide some background
> information, such as Batik version (or revision if using the source
> code [1]), Java version, operating system etc.. Also, are you able to
> create a reduced test case [2]?
Here's some sample code. Batik version is 1.7.
public class BoundsTest {
public static void main(String[] args) throws Exception {
ShapeNode innerNode = new ShapeNode();
// circle with diameter 10
innerNode.setShape( new Ellipse2D.Double(-5,-5,10,10) );
CompositeGraphicsNode outerNode = new CompositeGraphicsNode();
outerNode.add( innerNode );
System.out.println( outerNode.getBounds() );
// yields w=10.0,h=10.0
innerNode.setTransform(AffineTransform.getRotateInstance(Math.PI*0.25));
System.out.println( outerNode.getBounds() );
// yields w=14.142135623730951,h=14.142135623730951
// 10x10 square
innerNode.setShape( new Rectangle2D.Double(-5,-5,10,10) );
System.out.println( outerNode.getBounds() );
// yields w=14.142135623730951,h=14.142135623730951
System.out.println( Math.sqrt(200.0) );
// is 14.142135623730951, i.e. the diagonal of a 10x10 square
}
}
> Note that I haven't (yet) tried to reproduce the issue. Naturally,
> this may even be expected -- also I haven't (yet) double check the
> specification regarding this, though intuitively it would seem
> awkward. Currently, I'm just inviting you to share a bit more so one
> to be able to take a better look at this.
The javadoc entry reads
getBounds
Rectangle2D getBounds()
Returns the bounds of this node in user space. This includes primitive
paint, filtering, clipping and masking.
It doesn't actually say "includes transformations", so I guess it is all
well and intended. At least it's assured that the actual bounds are
always smaller than the clipping area returned by getBounds(). I just
wanted to know if there is already another, more accurate function which
would yield the actual bounds (which would definitely require more
computing and would hence be less efficient for clipping purposes).
Regards,
Gerrit
--
http://www.fastmail.fm - The professional email service
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Accuracy of bounding boxes for transformed shapes
Posted by th...@kodak.com.
Hi Gerrit,
Helder Magalhães <he...@gmail.com> wrote on 05/19/2009 11:56:15
AM:
> > When I display a bounding box for a rotated circle (which should have
> > the same bounds no matter how it is rotated) the box changes as if the
> > original square bounding box was part of the shape, e.g. the bounds
get
> > larger as you approach 45 degrees. That would mean that the bbox is in
> > fact a maximum bbox. The exact bounds can't be larger (so it's safe to
> > clip), but they could be smaller.
Correct. This saves a _lot_ of CPU time.
> > Is there another method that would yield the accurate bounds of
> > transformed shapes? My idea would be as follows:
Please try calling the 'getBBox' method from the SVG DOM
doing stuff directly with the GVT is likely to give "odd" results
like this.
You could also use the implementation of that method which
boils down to:
new SegmentList(node.getOutline()).getBounds2D();
Re: Accuracy of bounding boxes for transformed shapes
Posted by Helder Magalhães <he...@gmail.com>.
Hi Gerrit,
> When I display a bounding box for a rotated circle (which should have
> the same bounds no matter how it is rotated) the box changes as if the
> original square bounding box was part of the shape, e.g. the bounds get
> larger as you approach 45 degrees. That would mean that the bbox is in
> fact a maximum bbox. The exact bounds can't be larger (so it's safe to
> clip), but they could be smaller.
Wow, I'd say this is pretty weird. Please provide some background
information, such as Batik version (or revision if using the source
code [1]), Java version, operating system etc.. Also, are you able to
create a reduced test case [2]?
Note that I haven't (yet) tried to reproduce the issue. Naturally,
this may even be expected -- also I haven't (yet) double check the
specification regarding this, though intuitively it would seem
awkward. Currently, I'm just inviting you to share a bit more so one
to be able to take a better look at this.
> Is there another method that would yield the accurate bounds of
> transformed shapes? My idea would be as follows:
[...]
> Does something like this exist already? Or am I maybe missing something
> important here?
Seems like "getTransformToElement" [3] might help you. There's a great
sample, "How to get the boundingbox of an svg element" [4], which
proofs the concept.
> Many thanks and best regards,
> Gerrit
Hope this helps,
Helder
[1] http://xmlgraphics.apache.org/batik/download.html#Subversion+repository
[2] http://webkit.org/quality/reduction.html
[3] http://www.w3.org/TR/SVG11/ecmascript-binding.html
[4] http://my.opera.com/MacDev_ed/blog/2009/01/21/getting-boundingbox-of-svg-elements
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org