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 "V. de Weger" <ba...@beno-delft.nl> on 2006/08/19 00:00:57 UTC
how to handle resize
Hi, since some time I'm struggling with component resizes during the
rendering of a svg canvas. This is what happens:
- I create a parent panel (JPanel) with a splitter (JSplitPane) on it
- add e.g. another panel on the left of the splitter
- add a JSVGCanvas to a scrollpane (JSVGScrollPane) and add the scrollpane
to right of the splitter.
- make all components visible (by using setVisible() )
- start loading a svg file (setUri())
depending on the the users PC (seems some sort of race condition) I get a
gvtRenderingCancelled which is caused by the splitter being resized to its
divider location.
This all results in a cancelled rendering because GVTTreeRenderer.run() is
halted.
My question is: how to load the svg correctly when the size of the svgcanvas
is not fixed yet?
Vincent
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a5878258
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
I have some more information on this. I managed to get the retries out by
setting the scrollbars of the JScrollPane container to always visible (with
setScrollbarsAlwaysVisible(true)). I did this before by using
horizontal.setVisible(true) and the same for vertical and horizontalPanel.
The result in the canvas was a short painting of the scrollbars which get
removed during the rendering of the svg canvas. That probably was the
component resize I was struggling with.
Does this ring any bells?
Vincent
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a6517648
Sent from the Batik - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
Sorry for the delay, but I'm still working on it. not all the time ;-) The
canvas is indeed being painted before it is in the swing thread, but I'm not
sure if changing that also solves my rendering cancelled issues.
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a6274989
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
Thomas, I agree that it's odd ;-). I will try to figure out if it is already
in the Swing tree.
Vincent
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a6058265
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by th...@kodak.com.
Hi Vincent,
"V. de Weger" <ba...@beno-delft.nl> wrote on 08/30/2006 02:03:09 AM:
> When updateRenderingTransform is called prevComponentSize=0,0 and
getSize()
> returns 1,1. And 'at' equals 'vt', so the component gets repainted.
getSize returns 1,1? That's odd, that usually indicates that
the component isn't part of the Swing tree yet (doesn't have a size
really).
I tried to follow your output but I didn't have a lot of
luck. I take it you have two canvases stack on top of each other?
And you probably set the transform on the lower one when the top
one's transform changes?
Is it the lower one that does get redrawn?
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
Thomas, i've got some extra data from the loggings.
When updateRenderingTransform is called prevComponentSize=0,0 and getSize()
returns 1,1. And 'at' equals 'vt', so the component gets repainted.
Hope this helps.
Vincent
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a6052960
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
Thomas,
It doesn't seem to work. For completeness:
- I'm using the current trunc, so I changed the code of
AbstractJSVGComponent, not JSVGComponent.
After running the changed code I've added some extra System.out statements
in AbstractJGVTComponent to show some of the program flow. Every time
needRender is changed or used I logged it to the console. I also generated a
stacktrace when the rendering was halted. Together with the log4j statements
in my app I got the trace below. Hope it helps.
Vincent
04,531 INFO com.trafficits.svg.gispanel.SVGGisPanel:512 - loading
file:/d:/var/projects/TrafficMap/svg/geo/vcnl/geo-nl.svg
05,781 WARN com.trafficits.svg.TVSVGCanvas$1:288 - geo canvas: component
(com.trafficits.svg.gispanel.GeoSVGCanvas) is being resized, this may cause
rendering cancellation!
07,171 WARN com.trafficits.svg.TVSVGCanvas$1:288 - stl canvas: component
(com.trafficits.svg.stlpanel.StlSVGCanvas) is being resized, this may cause
rendering cancellation!
...
geoCanvas halted. Stack trace:
at org.apache.batik.util.HaltingThread.halt(Unknown Source)
at
org.apache.batik.swing.gvt.AbstractJGVTComponent.scheduleGVTRendering(Unknown
Source)
at
org.apache.batik.swing.gvt.AbstractJGVTComponent$1.componentResized(Unknown
Source)
at
java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:101)
at
java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:101)
at java.awt.Component.processComponentEvent(Component.java:4958)
at java.awt.Component.processEvent(Component.java:4912)
at java.awt.Container.processEvent(Container.java:1569)
at java.awt.Component.dispatchEventImpl(Component.java:3615)
at java.awt.Container.dispatchEventImpl(Container.java:1627)
at java.awt.Component.dispatchEvent(Component.java:3477)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:480)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
com.trafficits.svg.gispanel.GeoSVGCanvas[,0,0,487x509,alignmentX=null,alignmentY=null,border=,flags=288,maximumSize=java.awt.Dimension[width=1280,height=1024],minimumSize=java.awt.Dimension[width=100,height=100],preferredSize=java.awt.Dimension[width=200,height=200]]
AbstractJGVTComponent:scheduleGVTRendering: needRender set to true.
org.apache.batik.swing.JSVGCanvas$CanvasSVGListener@1cbe4b0
AbstractJGVTComponent:renderingStopped: needRender set to false.
14,984 WARN com.trafficits.svg.TVSVGCanvas$4:358 -
file:/d:/var/projects/TrafficMap/svg/geo/vcnl/geo-nl.svg rendering cancelled
org.apache.batik.swing.JSVGCanvas$CanvasSVGListener@1cbe4b0
AbstractJGVTComponent:gvtRenderingCompleted: repaint because
needRender=false.
16,578 INFO com.trafficits.svg.gispanel.SVGGisPanel$3:340 -
file:/d:/var/projects/TrafficMap/svg/geo/vcnl/geo-nl.svg
gvtRenderingCompleted RENDER GISPANEL TIME=11875
stlCanvas halted. Stack trace:
at org.apache.batik.util.HaltingThread.halt(Unknown Source)
at
org.apache.batik.swing.gvt.AbstractJGVTComponent.scheduleGVTRendering(Unknown
Source)
at
org.apache.batik.swing.gvt.AbstractJGVTComponent$1.componentResized(Unknown
Source)
at
java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:101)
at
java.awt.AWTEventMulticaster.componentResized(AWTEventMulticaster.java:101)
at java.awt.Component.processComponentEvent(Component.java:4958)
at java.awt.Component.processEvent(Component.java:4912)
at java.awt.Container.processEvent(Container.java:1569)
at java.awt.Component.dispatchEventImpl(Component.java:3615)
at java.awt.Container.dispatchEventImpl(Container.java:1627)
at java.awt.Component.dispatchEvent(Component.java:3477)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:480)
at
java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:201)
at
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:145)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:137)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:100)
17,671 WARN com.trafficits.svg.TVSVGCanvas$1:288 - stl canvas: component
(com.trafficits.svg.stlpanel.StlSVGCanvas) is being resized, this may cause
rendering cancellation!
com.trafficits.svg.stlpanel.StlSVGCanvas[,0,0,884x266,alignmentX=null,alignmentY=null,border=,flags=288,maximumSize=java.awt.Dimension[width=1280,height=1024],minimumSize=java.awt.Dimension[width=100,height=100],preferredSize=java.awt.Dimension[width=200,height=200]]
AbstractJGVTComponent:scheduleGVTRendering: needRender set to true.
org.apache.batik.swing.JSVGCanvas$CanvasSVGListener@2a657e
AbstractJGVTComponent:renderingStopped: needRender set to false.
18,718 WARN com.trafficits.svg.TVSVGCanvas$4:358 -
file:/d:/var/projects/TrafficMap/svg/stl/olga/styl_03040.svg rendering
cancelled
org.apache.batik.swing.JSVGCanvas$CanvasSVGListener@2a657e
AbstractJGVTComponent:gvtRenderingCompleted: repaint because
needRender=false.
18,984 INFO com.trafficits.svg.stlpanel.StlPanel$4:408 -
gvtRenderingCompleted RENDER STLPANEL TIME=14328
At the end of this run the geoCanvas showed a SVG, the stlCanvas didn't.
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a6035330
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
I will try this. Give me a couple of days to plan a 'before' and 'after'
test. Thanks.
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a5946720
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by th...@kodak.com.
Hi Vincent,
"V. de Weger" <ba...@beno-delft.nl> wrote on 08/23/2006 05:52:57 AM:
> My aim is however to prevent the resize completely, because it's a wast
of
> time to do the rendering twice ( .. isn't it ??). Is there a way to have
> batik wait for that, or should I take care of that in Swing?
Well, as I understand it this is very hard to avoid completely.
You would have to assume that the resize will take place and I'm
not sure that is a safe assumption.
> Thomas, that's true. The rendering is scheduled again, but when there is
a
> resize in the second run it looks as if it always goes into failed,
i.s.o.
> cancelled.
> I'm trying to understand the rescheduling: in AbstractJGVTComponent I
see a
> listener for a component resize that reschedules the rendering, however
it
> checks for updateRenderingTransform() which always returns false. Am I
> missing something??
Ahhh, I think I see the problem. In the resize handler it avoids
scheduling a new gvtRendering if the result would be the same rendering
as it already had. Except in this case it doesn't have any good rendering
so it really needs to do the rendering...
I think the core of the problem is the handling of 'oldD'. Can you
try replacing the JSVGComponent.updateRenderingTransform function:
protected boolean updateRenderingTransform() {
if ((svgDocument == null) || (gvtRoot == null))
return false;
try {
SVGSVGElement elt = svgDocument.getRootElement();
Dimension d = getSize();
Dimension oldD = prevComponentSize;
prevComponentSize = d;
if (d.width < 1) d.width = 1;
if (d.height < 1) d.height = 1;
final AffineTransform at = calculateViewingTransform
(fragmentIdentifier, elt);
AffineTransform vt = getViewingTransform();
if (at.equals(vt)) {
// No new transform
// Only repaint if size really changed.
return ((oldD == null) ||
(oldD.width != d.width) || (oldD.height !=
d.height));
}
if (!recenterOnResize)
return true;
if (oldD == null) oldD = d;
// Here we map the old center of the component down to
// the user coodinate system with the old viewing
// transform and then back to the screen with the
// new viewing transform. We then adjust the rendering
// transform so it lands in the same place.
Point2D pt = new Point2D.Float(oldD.width/2.0f,
oldD.height/2.0f);
AffineTransform rendAT = getRenderingTransform();
if (rendAT != null) {
try {
AffineTransform invRendAT = rendAT.createInverse();
pt = invRendAT.transform(pt, null);
} catch (NoninvertibleTransformException e) { }
}
if (vt != null) {
try {
AffineTransform invVT = vt.createInverse();
pt = invVT.transform(pt, null);
} catch (NoninvertibleTransformException e) { }
}
if (at != null)
pt = at.transform(pt, null);
if (rendAT != null)
pt = rendAT.transform(pt, null);
// Now figure out how far we need to shift things
// to get the center point to line up again.
float dx = (float)((d.width/2.0f) -pt.getX());
float dy = (float)((d.height/2.0f)-pt.getY());
// Round the values to nearest integer.
dx = (int)((dx < 0)?(dx - .5):(dx + .5));
dy = (int)((dy < 0)?(dy - .5):(dy + .5));
if ((dx != 0) || (dy != 0)) {
rendAT.preConcatenate
(AffineTransform.getTranslateInstance(dx, dy));
setRenderingTransform(rendAT, false);
}
synchronized (this) {
viewingTransform = at;
}
Runnable r = new Runnable() {
AffineTransform myAT = at;
CanvasGraphicsNode myCGN = getCanvasGraphicsNode();
public void run() {
synchronized (JSVGComponent.this) {
myCGN.setViewingTransform(myAT);
if (viewingTransform == myAT)
viewingTransform = null;
}
}
};
UpdateManager um = getUpdateManager();
if (um != null) um.getUpdateRunnableQueue().invokeLater(r);
else r.run();
} catch (BridgeException e) {
userAgent.displayError(e);
}
return true;
}
>
> Vincent
>
>
>
> >
> > This shouldn't really be a problem because it should queue another
> > render request. Is that not happening for some reason?
> >
> >
> >
>
> --
> View this message in context:
http://www.nabble.com/how-to-handle-resize-
> tf2129806.html#a5941300
> Sent from the Batik - Users forum at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by "V. de Weger" <ba...@beno-delft.nl>.
Thomas, that's true. The rendering is scheduled again, but when there is a
resize in the second run it looks as if it always goes into failed, i.s.o.
cancelled.
My aim is however to prevent the resize completely, because it's a wast of
time to do the rendering twice ( .. isn't it ??). Is there a way to have
batik wait for that, or should I take care of that in Swing?
I'm trying to understand the rescheduling: in AbstractJGVTComponent I see a
listener for a component resize that reschedules the rendering, however it
checks for updateRenderingTransform() which always returns false. Am I
missing something??
Vincent
>
> This shouldn't really be a problem because it should queue another
> render request. Is that not happening for some reason?
>
>
>
--
View this message in context: http://www.nabble.com/how-to-handle-resize-tf2129806.html#a5941300
Sent from the Batik - Users forum at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: how to handle resize
Posted by th...@kodak.com.
Hi Vincent,
See below,
"V. de Weger" <ba...@beno-delft.nl> wrote on 08/18/2006 06:00:57 PM:
> Hi, since some time I'm struggling with component resizes during the
> rendering of a svg canvas. This is what happens:
>
> - I create a parent panel (JPanel) with a splitter (JSplitPane) on it
> - add e.g. another panel on the left of the splitter
> - add a JSVGCanvas to a scrollpane (JSVGScrollPane) and add the
scrollpane
> to right of the splitter.
> - make all components visible (by using setVisible() )
> - start loading a svg file (setUri())
>
> depending on the the users PC (seems some sort of race condition) I get
a
> gvtRenderingCancelled which is caused by the splitter being resized to
its
> divider location.
>
> This all results in a cancelled rendering because GVTTreeRenderer.run()
is
> halted.
This shouldn't really be a problem because it should queue another
render request. Is that not happening for some reason?
> My question is: how to load the svg correctly when the size of the
svgcanvas
> is not fixed yet?
It should just happen.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org