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 André Ávila <as...@nextech.com.br> on 2006/03/19 18:49:01 UTC
Rendering with JGVTComponent
Hi,
I'm trying to render a document in a JGVTComponent, but I still get a blank screen. The SVG comes from a ByteBuffer. Here we go:
JGVTComponent canvas //... part of the GUI
ByteBuffer svgFile //...
BufferedInputStream svgFileStream = new BufferedInputStream(new ByteArrayInputStream(svgFile));
// Parse the memory buffer
String parser = XMLResourceDescriptor.getXMLParserClassName();
SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
SVGDocument doc = f.createSVGDocument(null, svgFileStream);
// Build the GVT tree
UserAgent userAgent = new UserAgentAdapter();
DocumentLoader loader = new DocumentLoader(userAgent);
BridgeContext ctx = new BridgeContext(userAgent, loader);
ctx.setDynamicState(BridgeContext.DYNAMIC);
GVTBuilder builder = new GVTBuilder();
GraphicsNode rootNode = builder.build(ctx, doc);
canvas.setGraphicsNode(rootNode);
Now, am I missing something? Is the GVT tree building code ok?
Another question is, after rendering the document to the JGVTComponent, how can I dispose of the DOM?
I never worked with JGVTComponent, so I'm a little lost.
Re: Rendering with JGVTComponent
Posted by André Ávila <as...@nextech.com.br>.
Hi Thomas.
> The fix is now in SVN. For static documents that only use AWT Fonts
> the Document can now go to GC once the GVT tree is built (I've attached
> a small sample app that shows this).
This is great news! Downloading now.
> Note that SVG Fonts currently still hold a reference to the DOM.
> This can probably also be fixed but is a bigger job. Since I doubt
> you need to use SVG Fonts I figured I put out what I have.
This is fine. SVG fonts are not really an issue for me.
> If you have split the document I would build the GVT tree for them
> sequentially and append the generated GVT tree's. This way you will only
> have the DOM for one piece in memory at a time, and you won't have to
> worry about synching multiple canvases.
Yes, I was hoping I could do that (build only one GVT tree). Otherwise I
would have to keep 10-20 synchronized canvases, and I doubt it would be an
easy task.
Many thanks again for all your support, Thomas!
I'll build your new package and then I'll let you know how things are going.
Best regards,
André
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rendering with JGVTComponent
Posted by th...@kodak.com.
Hi Andre,
André Ávila <as...@nextech.com.br> wrote on 03/22/2006 07:53:45 AM:
> I will eagerly wait for your commit of this fix, then. Please let us now
> when you do it, ok?
The fix is now in SVN. For static documents that only use AWT Fonts
the Document can now go to GC once the GVT tree is built (I've attached
a small sample app that shows this).
Note that SVG Fonts currently still hold a reference to the DOM.
This can probably also be fixed but is a bigger job. Since I doubt
you need to use SVG Fonts I figured I put out what I have.
> In the meantime, I'm doing some tests on splitting the big SVGs and
> displaying them on layered, transparent canvases. I'm not sure as
whether
> this will be enough to render the big documents, though.
If you have split the document I would build the GVT tree for them
sequentially and append the generated GVT tree's. This way you will only
have the DOM for one piece in memory at a time, and you won't have to
worry about synching multiple canvases.
Anyway good luck!
> I think I can try to come up with some sort of server-side rendering,
> sending to the clients the components with the files already rendered. I
> haven't explored this possibility yet, so I'll see if I can get
something up
> and running before asking more dumb questions. :)
package org.test;
import java.util.ArrayList;
import java.util.List;
import java.lang.ref.SoftReference;
import org.w3c.dom.Document;
import org.apache.batik.bridge.BridgeContext;
import org.apache.batik.bridge.DocumentLoader;
import org.apache.batik.bridge.GVTBuilder;
import org.apache.batik.bridge.UserAgentAdapter;
import org.apache.batik.gvt.GraphicsNode;
public class GVTGC {
SoftReference sr;
public GVTGC() {
}
public GraphicsNode buildGN(String file) {
UserAgentAdapter svgUA = new UserAgentAdapter();
BridgeContext bridgeContext = new BridgeContext(svgUA);
DocumentLoader documentLoader = new DocumentLoader(svgUA);
Document d = null;
try {
java.io.File fi = new java.io.File(file);
d = documentLoader.loadDocument(fi.toURL().toString());
} catch (Exception e) { e.printStackTrace();}
GVTBuilder builder = new GVTBuilder();
sr = new SoftReference(d);
return builder.build(bridgeContext, d);
}
final static int ALLOC_SZ=10000; // 1KB
public static void main(String args[]) {
try {
GVTGC tst = new GVTGC();
GraphicsNode gn = tst.buildGN(args[0]);
System.err.println("Document SoftRef: " + tst.sr.get());
System.err.println("GraphicsNode: " + gn);
System.err.println("Forcing OutOfMemeory error");
List l = new ArrayList();
try {
while (true) {
l.add(new byte[ALLOC_SZ]);
}
} catch (OutOfMemoryError oom) { }
finally { l = null; }
System.err.println("After OutOfMemeory error:");
System.err.println("Document SoftRef: " + tst.sr.get());
System.err.println("GraphicsNode: " + gn);
} finally { System.exit(0); }
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rendering with JGVTComponent
Posted by André Ávila <as...@nextech.com.br>.
Thank you a lot for your time, Thomas. Things are a little clearer now.
I will eagerly wait for your commit of this fix, then. Please let us now
when you do it, ok?
In the meantime, I'm doing some tests on splitting the big SVGs and
displaying them on layered, transparent canvases. I'm not sure as whether
this will be enough to render the big documents, though.
I think I can try to come up with some sort of server-side rendering,
sending to the clients the components with the files aready rendered. I
haven't explored this possibility yet, so I'll see if I can get something up
and running before asking more dumb questions. :)
----- Original Message -----
From: <th...@kodak.com>
To: <ba...@xmlgraphics.apache.org>
Cc: <ba...@xmlgraphics.apache.org>
Sent: Tuesday, March 21, 2006 11:21 PM
Subject: Re: Rendering with JGVTComponent
> Hi Andre,
>
> André Ávila <as...@nextech.com.br> wrote on 03/21/2006 08:22:13 AM:
>
> > I was curious to see if there would be any gain in performance by using
> the
> > JGVTComponent instead of JSVGCanvas, but my impression is that there's
> none.
> > Shouldn't the JGVTComponent rendering be faster? This is just out of
> > curiosity, I am not complaining about it. :)
>
> No the rendering will be essentially identical. When you have SVG
> the SVG DOM basically just manipulates the GVT tree. In the static case
> the straight GVT tree will be exactly the same as the SVG case.
>
> > So, just to clarify things. Both JGVTComponent and JSVGCanvas build the
> DOM,
> > right? The idea of using JGVTComponent is get rid of the DOM by garbage
> > collecting it after the call to setGraphicsNode. So, basically,
> > JGVTComponent.setGraphicsNode() will use the same amount of memory as
> > JSVGCanvas.setDocument(). Is that correct?
>
> There will be a period when you will have the DOM and the GVT tree
> in memory. However after this 'bottleneck' the DOM should go to GC.
> So it may not really reduce the 'max' memory usage it will help during
> the normal display.
>
> > Then, the next step in supporting huge files will be removing the DOM
> from
> > the JGVTComponent. I'm a little worried about the references to text
> that
> > you mentioned, and it is very good news that you are looking into this.
> In
> > case I decide to get my hands a little dirty, is it possible to get rid
> of
> > those references, say, by subclassing JGVTComponent and nullifying them?
> Is
> > there any better approach?
>
> The main reference is in the AttributedCharacterIterator in particular
> the TEXT_COMPOUND_DELIMITER. It is not simple to clear these. They are
> also used for a number of things. The biggest problem is that this is
> used to support lots of operations during the setup for rendering.
> I suppose once the GlyphLayouts are created you might be able to
> clear the AttributeCharacterIterators, or replace them with unattributed
> ACI's.
>
> I'm very close on my solution.
>
>
> >
> > Once again, many thanks for all your help!
> >
> > ----- Original Message -----
> > From: <th...@kodak.com>
> > To: <ba...@xmlgraphics.apache.org>
> > Cc: <ba...@xmlgraphics.apache.org>
> > Sent: Monday, March 20, 2006 10:30 AM
> > Subject: Re: Rendering with JGVTComponent
> >
> >
> > > Hi Andre,
> > >
> > > André Ávila <as...@nextech.com.br> wrote on 03/20/2006 08:00:48 AM:
> > >
> > > > I'm sending a sample file as you suggested. They are indeed setting
> the
> > > > width, height and viewbox, like you said. Could this be a problem?
> > >
> > > Actually they are setting viewbox but not width/height.
> > > The UserAgentAdapter that you are using returns a fairly bogus
> > > default viewport size (1x1). I would suggest overriding this
> > > method to return the size of your JGVTComponent (you will
> > > probably want to look at all the methods in this Adapter as
> > > many will want/need to be replaced for a graphical context).
> > >
> > > There is something close to what you want in:
> > > batik.swing.svg.SVGUserAgentGUIAdapter
> > >
> > > Alternately if your document provides a width and height
> > > you will get something closer to what you want...
> > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: <th...@kodak.com>
> > > > To: <ba...@xmlgraphics.apache.org>
> > > > Cc: <ba...@xmlgraphics.apache.org>
> > > > Sent: Monday, March 20, 2006 9:33 AM
> > > > Subject: Re: Rendering with JGVTComponent
> > > >
> > > >
> > > > > Hi André,
> > > > >
> > > > > André Ávila <as...@nextech.com.br> wrote on 03/20/2006 07:23:55
> AM:
> > > > >
> > > > > > It looks like it is a problem with our SVGs. I tried the Batik
> > > sample
> > > > > files,
> > > > > > and they all work fine in my JGVTComponent. Our files don't.
> > > Strangely
> > > > > > enough, those same files are correctly rendered in a JSVGCanvas.
> > > > >
> > > > > Do they use Scripting to build the document (based on the
> > > > > 'onload' attribute or something)? Do they have width/height
> > > > > & viewBox? I'm not sure those will be applied with the
> JGVTComponent
> > > > > (they can be it's just that you will need to provide the viewing
> > > > > transform).
> > > > >
> > > > > > I looked at our files and didn't see anything wrong. I think
> they
> > > are
> > > > > not
> > > > > > malformed since they work in JSVGCanvas (and Firefox, BTW).
> > > > >
> > > > > Can you post a small representative example?
> > > > >
> > > > > > Do you have any clues on what could be the problem? Are there
> any
> > > > > elements
> > > > > > that could be causing this behavior?
> > > > > >
> > > > > > I'm using the latest SVN version (06-03-16).
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: <th...@kodak.com>
> > > > > > To: <ba...@xmlgraphics.apache.org>
> > > > > > Cc: <ba...@xmlgraphics.apache.org>
> > > > > > Sent: Sunday, March 19, 2006 3:47 PM
> > > > > > Subject: Re: Rendering with JGVTComponent
> > > > > >
> > > > > >
> > > > > > > Hi André,
> > > > > > >
> > > > > > > André Ávila <as...@nextech.com.br> wrote on 03/19/2006
> 12:49:01
> > > PM:
> > > > > > >
> > > > > > > > I'm trying to render a document in a JGVTComponent, but I
> still
> > > get
> > > > > a
> > > > > > > blank
> > > > > > > > screen. The SVG comes from a ByteBuffer. Here we go:
> > > > > > > >
> > > > > > > >
> > > > > > > > JGVTComponent canvas //... part of the GUI
> > > > > > >
> > > > > > > Are you fairly sure it has a size?
> > > > > > > You might try setting it's perferredSize.
> > > > > > >
> > > > > > > > ByteBuffer svgFile //...
> > > > > > > >
> > > > > > > > BufferedInputStream svgFileStream = new
> BufferedInputStream(new
> > > > > > > > ByteArrayInputStream(svgFile));
> > > > > > > >
> > > > > > > > // Parse the memory buffer
> > > > > > > > String parser =
> XMLResourceDescriptor.getXMLParserClassName();
> > > > > > > > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > > > > > > > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> > > > > > > >
> > > > > > > > // Build the GVT tree
> > > > > > > > UserAgent userAgent = new UserAgentAdapter();
> > > > > > > > DocumentLoader loader = new DocumentLoader(userAgent);
> > > > > > > > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > > > > > > > ctx.setDynamicState(BridgeContext.DYNAMIC);
> > > > > > >
> > > > > > > You want/need to set this as 'BridgeContext.STATIC'
> > > > > > >
> > > > > > > > GVTBuilder builder = new GVTBuilder();
> > > > > > > > GraphicsNode rootNode = builder.build(ctx, doc);
> > > > > > > >
> > > > > > > > canvas.setGraphicsNode(rootNode);
> > > > > > > >
> > > > > > > >
> > > > > > > > Now, am I missing something? Is the GVT tree building code
> ok?
> > > > > > >
> > > > > > > Everything looks pretty good to me.
> > > > > > >
> > > > > > > > Another question is, after rendering the document to the
> > > > > JGVTComponent,
> > > > > > > how
> > > > > > > > can I dispose of the DOM?
> > > > > > >
> > > > > > > If you remove all your references to it (i.e. set doc=null)
> > > then
> > > > > > > it should just be collected by the JVM. However as I said
> text
> > > > > > > currently holds a hard reference into the DOM which will
> prevent
> > > > > > > the document from really going to GC. I'm looking at ways to
> > > > > > > fix this...
> > > > > > >
> > > > > > > > I never worked with JGVTComponent, so I'm a little lost.
> > > > > > >
> > > > > > > I would suggest creating a small test app so you can
> > > > > > > get the GVT Canvas up and running in isolation (and also I
> > > > > > > can help you get it going).
> > > > > > >
> > > > > > >
> > > > > > >
> > > ---------------------------------------------------------------------
> > > > > > > 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
> > > > > >
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail:
> batik-users-unsubscribe@xmlgraphics.apache.org
> > > > > For additional commands, e-mail:
> > > batik-users-help@xmlgraphics.apache.org
> > > > >
> > > > >
> > > > [attachment "sample.svg" deleted by Thomas E. DeWeese/449433/EKC]
> > > >
> ---------------------------------------------------------------------
> > > > 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
> > >
> > >
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rendering with JGVTComponent
Posted by th...@kodak.com.
Hi Andre,
André Ávila <as...@nextech.com.br> wrote on 03/21/2006 08:22:13 AM:
> I was curious to see if there would be any gain in performance by using
the
> JGVTComponent instead of JSVGCanvas, but my impression is that there's
none.
> Shouldn't the JGVTComponent rendering be faster? This is just out of
> curiosity, I am not complaining about it. :)
No the rendering will be essentially identical. When you have SVG
the SVG DOM basically just manipulates the GVT tree. In the static case
the straight GVT tree will be exactly the same as the SVG case.
> So, just to clarify things. Both JGVTComponent and JSVGCanvas build the
DOM,
> right? The idea of using JGVTComponent is get rid of the DOM by garbage
> collecting it after the call to setGraphicsNode. So, basically,
> JGVTComponent.setGraphicsNode() will use the same amount of memory as
> JSVGCanvas.setDocument(). Is that correct?
There will be a period when you will have the DOM and the GVT tree
in memory. However after this 'bottleneck' the DOM should go to GC.
So it may not really reduce the 'max' memory usage it will help during
the normal display.
> Then, the next step in supporting huge files will be removing the DOM
from
> the JGVTComponent. I'm a little worried about the references to text
that
> you mentioned, and it is very good news that you are looking into this.
In
> case I decide to get my hands a little dirty, is it possible to get rid
of
> those references, say, by subclassing JGVTComponent and nullifying them?
Is
> there any better approach?
The main reference is in the AttributedCharacterIterator in particular
the TEXT_COMPOUND_DELIMITER. It is not simple to clear these. They are
also used for a number of things. The biggest problem is that this is
used to support lots of operations during the setup for rendering.
I suppose once the GlyphLayouts are created you might be able to
clear the AttributeCharacterIterators, or replace them with unattributed
ACI's.
I'm very close on my solution.
>
> Once again, many thanks for all your help!
>
> ----- Original Message -----
> From: <th...@kodak.com>
> To: <ba...@xmlgraphics.apache.org>
> Cc: <ba...@xmlgraphics.apache.org>
> Sent: Monday, March 20, 2006 10:30 AM
> Subject: Re: Rendering with JGVTComponent
>
>
> > Hi Andre,
> >
> > André Ávila <as...@nextech.com.br> wrote on 03/20/2006 08:00:48 AM:
> >
> > > I'm sending a sample file as you suggested. They are indeed setting
the
> > > width, height and viewbox, like you said. Could this be a problem?
> >
> > Actually they are setting viewbox but not width/height.
> > The UserAgentAdapter that you are using returns a fairly bogus
> > default viewport size (1x1). I would suggest overriding this
> > method to return the size of your JGVTComponent (you will
> > probably want to look at all the methods in this Adapter as
> > many will want/need to be replaced for a graphical context).
> >
> > There is something close to what you want in:
> > batik.swing.svg.SVGUserAgentGUIAdapter
> >
> > Alternately if your document provides a width and height
> > you will get something closer to what you want...
> >
> > >
> > >
> > > ----- Original Message -----
> > > From: <th...@kodak.com>
> > > To: <ba...@xmlgraphics.apache.org>
> > > Cc: <ba...@xmlgraphics.apache.org>
> > > Sent: Monday, March 20, 2006 9:33 AM
> > > Subject: Re: Rendering with JGVTComponent
> > >
> > >
> > > > Hi André,
> > > >
> > > > André Ávila <as...@nextech.com.br> wrote on 03/20/2006 07:23:55
AM:
> > > >
> > > > > It looks like it is a problem with our SVGs. I tried the Batik
> > sample
> > > > files,
> > > > > and they all work fine in my JGVTComponent. Our files don't.
> > Strangely
> > > > > enough, those same files are correctly rendered in a JSVGCanvas.
> > > >
> > > > Do they use Scripting to build the document (based on the
> > > > 'onload' attribute or something)? Do they have width/height
> > > > & viewBox? I'm not sure those will be applied with the
JGVTComponent
> > > > (they can be it's just that you will need to provide the viewing
> > > > transform).
> > > >
> > > > > I looked at our files and didn't see anything wrong. I think
they
> > are
> > > > not
> > > > > malformed since they work in JSVGCanvas (and Firefox, BTW).
> > > >
> > > > Can you post a small representative example?
> > > >
> > > > > Do you have any clues on what could be the problem? Are there
any
> > > > elements
> > > > > that could be causing this behavior?
> > > > >
> > > > > I'm using the latest SVN version (06-03-16).
> > > > >
> > > > > ----- Original Message -----
> > > > > From: <th...@kodak.com>
> > > > > To: <ba...@xmlgraphics.apache.org>
> > > > > Cc: <ba...@xmlgraphics.apache.org>
> > > > > Sent: Sunday, March 19, 2006 3:47 PM
> > > > > Subject: Re: Rendering with JGVTComponent
> > > > >
> > > > >
> > > > > > Hi André,
> > > > > >
> > > > > > André Ávila <as...@nextech.com.br> wrote on 03/19/2006
12:49:01
> > PM:
> > > > > >
> > > > > > > I'm trying to render a document in a JGVTComponent, but I
still
> > get
> > > > a
> > > > > > blank
> > > > > > > screen. The SVG comes from a ByteBuffer. Here we go:
> > > > > > >
> > > > > > >
> > > > > > > JGVTComponent canvas //... part of the GUI
> > > > > >
> > > > > > Are you fairly sure it has a size?
> > > > > > You might try setting it's perferredSize.
> > > > > >
> > > > > > > ByteBuffer svgFile //...
> > > > > > >
> > > > > > > BufferedInputStream svgFileStream = new
BufferedInputStream(new
> > > > > > > ByteArrayInputStream(svgFile));
> > > > > > >
> > > > > > > // Parse the memory buffer
> > > > > > > String parser =
XMLResourceDescriptor.getXMLParserClassName();
> > > > > > > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > > > > > > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> > > > > > >
> > > > > > > // Build the GVT tree
> > > > > > > UserAgent userAgent = new UserAgentAdapter();
> > > > > > > DocumentLoader loader = new DocumentLoader(userAgent);
> > > > > > > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > > > > > > ctx.setDynamicState(BridgeContext.DYNAMIC);
> > > > > >
> > > > > > You want/need to set this as 'BridgeContext.STATIC'
> > > > > >
> > > > > > > GVTBuilder builder = new GVTBuilder();
> > > > > > > GraphicsNode rootNode = builder.build(ctx, doc);
> > > > > > >
> > > > > > > canvas.setGraphicsNode(rootNode);
> > > > > > >
> > > > > > >
> > > > > > > Now, am I missing something? Is the GVT tree building code
ok?
> > > > > >
> > > > > > Everything looks pretty good to me.
> > > > > >
> > > > > > > Another question is, after rendering the document to the
> > > > JGVTComponent,
> > > > > > how
> > > > > > > can I dispose of the DOM?
> > > > > >
> > > > > > If you remove all your references to it (i.e. set doc=null)
> > then
> > > > > > it should just be collected by the JVM. However as I said
text
> > > > > > currently holds a hard reference into the DOM which will
prevent
> > > > > > the document from really going to GC. I'm looking at ways to
> > > > > > fix this...
> > > > > >
> > > > > > > I never worked with JGVTComponent, so I'm a little lost.
> > > > > >
> > > > > > I would suggest creating a small test app so you can
> > > > > > get the GVT Canvas up and running in isolation (and also I
> > > > > > can help you get it going).
> > > > > >
> > > > > >
> > > > > >
> > ---------------------------------------------------------------------
> > > > > > 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
> > > > >
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
batik-users-unsubscribe@xmlgraphics.apache.org
> > > > For additional commands, e-mail:
> > batik-users-help@xmlgraphics.apache.org
> > > >
> > > >
> > > [attachment "sample.svg" deleted by Thomas E. DeWeese/449433/EKC]
> > >
---------------------------------------------------------------------
> > > 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
> >
> >
>
>
> ---------------------------------------------------------------------
> 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: Rendering with JGVTComponent
Posted by André Ávila <as...@nextech.com.br>.
Hi Thomas,
You nailed it. Overriding the getViewportSize() method did the trick. It
works like a charm now.
I was curious to see if there would be any gain in performance by using the
JGVTComponent instead of JSVGCanvas, but my impression is that there's none.
Shouldn't the JGVTComponent rendering be faster? This is just out of
curiosity, I am not complaining about it. :)
So, just to clarify things. Both JGVTComponent and JSVGCanvas build the DOM,
right? The idea of using JGVTComponent is get rid of the DOM by garbage
collecting it after the call to setGraphicsNode. So, basically,
JGVTComponent.setGraphicsNode() will use the same amount of memory as
JSVGCanvas.setDocument(). Is that correct?
Then, the next step in supporting huge files will be removing the DOM from
the JGVTComponent. I'm a little worried about the references to text that
you mentioned, and it is very good news that you are looking into this. In
case I decide to get my hands a little dirty, is it possible to get rid of
those references, say, by subclassing JGVTComponent and nullifying them? Is
there any better approach?
Once again, many thanks for all your help!
----- Original Message -----
From: <th...@kodak.com>
To: <ba...@xmlgraphics.apache.org>
Cc: <ba...@xmlgraphics.apache.org>
Sent: Monday, March 20, 2006 10:30 AM
Subject: Re: Rendering with JGVTComponent
> Hi Andre,
>
> André Ávila <as...@nextech.com.br> wrote on 03/20/2006 08:00:48 AM:
>
> > I'm sending a sample file as you suggested. They are indeed setting the
> > width, height and viewbox, like you said. Could this be a problem?
>
> Actually they are setting viewbox but not width/height.
> The UserAgentAdapter that you are using returns a fairly bogus
> default viewport size (1x1). I would suggest overriding this
> method to return the size of your JGVTComponent (you will
> probably want to look at all the methods in this Adapter as
> many will want/need to be replaced for a graphical context).
>
> There is something close to what you want in:
> batik.swing.svg.SVGUserAgentGUIAdapter
>
> Alternately if your document provides a width and height
> you will get something closer to what you want...
>
> >
> >
> > ----- Original Message -----
> > From: <th...@kodak.com>
> > To: <ba...@xmlgraphics.apache.org>
> > Cc: <ba...@xmlgraphics.apache.org>
> > Sent: Monday, March 20, 2006 9:33 AM
> > Subject: Re: Rendering with JGVTComponent
> >
> >
> > > Hi André,
> > >
> > > André Ávila <as...@nextech.com.br> wrote on 03/20/2006 07:23:55 AM:
> > >
> > > > It looks like it is a problem with our SVGs. I tried the Batik
> sample
> > > files,
> > > > and they all work fine in my JGVTComponent. Our files don't.
> Strangely
> > > > enough, those same files are correctly rendered in a JSVGCanvas.
> > >
> > > Do they use Scripting to build the document (based on the
> > > 'onload' attribute or something)? Do they have width/height
> > > & viewBox? I'm not sure those will be applied with the JGVTComponent
> > > (they can be it's just that you will need to provide the viewing
> > > transform).
> > >
> > > > I looked at our files and didn't see anything wrong. I think they
> are
> > > not
> > > > malformed since they work in JSVGCanvas (and Firefox, BTW).
> > >
> > > Can you post a small representative example?
> > >
> > > > Do you have any clues on what could be the problem? Are there any
> > > elements
> > > > that could be causing this behavior?
> > > >
> > > > I'm using the latest SVN version (06-03-16).
> > > >
> > > > ----- Original Message -----
> > > > From: <th...@kodak.com>
> > > > To: <ba...@xmlgraphics.apache.org>
> > > > Cc: <ba...@xmlgraphics.apache.org>
> > > > Sent: Sunday, March 19, 2006 3:47 PM
> > > > Subject: Re: Rendering with JGVTComponent
> > > >
> > > >
> > > > > Hi André,
> > > > >
> > > > > André Ávila <as...@nextech.com.br> wrote on 03/19/2006 12:49:01
> PM:
> > > > >
> > > > > > I'm trying to render a document in a JGVTComponent, but I still
> get
> > > a
> > > > > blank
> > > > > > screen. The SVG comes from a ByteBuffer. Here we go:
> > > > > >
> > > > > >
> > > > > > JGVTComponent canvas //... part of the GUI
> > > > >
> > > > > Are you fairly sure it has a size?
> > > > > You might try setting it's perferredSize.
> > > > >
> > > > > > ByteBuffer svgFile //...
> > > > > >
> > > > > > BufferedInputStream svgFileStream = new BufferedInputStream(new
> > > > > > ByteArrayInputStream(svgFile));
> > > > > >
> > > > > > // Parse the memory buffer
> > > > > > String parser = XMLResourceDescriptor.getXMLParserClassName();
> > > > > > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > > > > > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> > > > > >
> > > > > > // Build the GVT tree
> > > > > > UserAgent userAgent = new UserAgentAdapter();
> > > > > > DocumentLoader loader = new DocumentLoader(userAgent);
> > > > > > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > > > > > ctx.setDynamicState(BridgeContext.DYNAMIC);
> > > > >
> > > > > You want/need to set this as 'BridgeContext.STATIC'
> > > > >
> > > > > > GVTBuilder builder = new GVTBuilder();
> > > > > > GraphicsNode rootNode = builder.build(ctx, doc);
> > > > > >
> > > > > > canvas.setGraphicsNode(rootNode);
> > > > > >
> > > > > >
> > > > > > Now, am I missing something? Is the GVT tree building code ok?
> > > > >
> > > > > Everything looks pretty good to me.
> > > > >
> > > > > > Another question is, after rendering the document to the
> > > JGVTComponent,
> > > > > how
> > > > > > can I dispose of the DOM?
> > > > >
> > > > > If you remove all your references to it (i.e. set doc=null)
> then
> > > > > it should just be collected by the JVM. However as I said text
> > > > > currently holds a hard reference into the DOM which will prevent
> > > > > the document from really going to GC. I'm looking at ways to
> > > > > fix this...
> > > > >
> > > > > > I never worked with JGVTComponent, so I'm a little lost.
> > > > >
> > > > > I would suggest creating a small test app so you can
> > > > > get the GVT Canvas up and running in isolation (and also I
> > > > > can help you get it going).
> > > > >
> > > > >
> > > > >
> ---------------------------------------------------------------------
> > > > > 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
> > > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > > For additional commands, e-mail:
> batik-users-help@xmlgraphics.apache.org
> > >
> > >
> > [attachment "sample.svg" deleted by Thomas E. DeWeese/449433/EKC]
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rendering with JGVTComponent
Posted by th...@kodak.com.
Hi Andre,
André Ávila <as...@nextech.com.br> wrote on 03/20/2006 08:00:48 AM:
> I'm sending a sample file as you suggested. They are indeed setting the
> width, height and viewbox, like you said. Could this be a problem?
Actually they are setting viewbox but not width/height.
The UserAgentAdapter that you are using returns a fairly bogus
default viewport size (1x1). I would suggest overriding this
method to return the size of your JGVTComponent (you will
probably want to look at all the methods in this Adapter as
many will want/need to be replaced for a graphical context).
There is something close to what you want in:
batik.swing.svg.SVGUserAgentGUIAdapter
Alternately if your document provides a width and height
you will get something closer to what you want...
>
>
> ----- Original Message -----
> From: <th...@kodak.com>
> To: <ba...@xmlgraphics.apache.org>
> Cc: <ba...@xmlgraphics.apache.org>
> Sent: Monday, March 20, 2006 9:33 AM
> Subject: Re: Rendering with JGVTComponent
>
>
> > Hi André,
> >
> > André Ávila <as...@nextech.com.br> wrote on 03/20/2006 07:23:55 AM:
> >
> > > It looks like it is a problem with our SVGs. I tried the Batik
sample
> > files,
> > > and they all work fine in my JGVTComponent. Our files don't.
Strangely
> > > enough, those same files are correctly rendered in a JSVGCanvas.
> >
> > Do they use Scripting to build the document (based on the
> > 'onload' attribute or something)? Do they have width/height
> > & viewBox? I'm not sure those will be applied with the JGVTComponent
> > (they can be it's just that you will need to provide the viewing
> > transform).
> >
> > > I looked at our files and didn't see anything wrong. I think they
are
> > not
> > > malformed since they work in JSVGCanvas (and Firefox, BTW).
> >
> > Can you post a small representative example?
> >
> > > Do you have any clues on what could be the problem? Are there any
> > elements
> > > that could be causing this behavior?
> > >
> > > I'm using the latest SVN version (06-03-16).
> > >
> > > ----- Original Message -----
> > > From: <th...@kodak.com>
> > > To: <ba...@xmlgraphics.apache.org>
> > > Cc: <ba...@xmlgraphics.apache.org>
> > > Sent: Sunday, March 19, 2006 3:47 PM
> > > Subject: Re: Rendering with JGVTComponent
> > >
> > >
> > > > Hi André,
> > > >
> > > > André Ávila <as...@nextech.com.br> wrote on 03/19/2006 12:49:01
PM:
> > > >
> > > > > I'm trying to render a document in a JGVTComponent, but I still
get
> > a
> > > > blank
> > > > > screen. The SVG comes from a ByteBuffer. Here we go:
> > > > >
> > > > >
> > > > > JGVTComponent canvas //... part of the GUI
> > > >
> > > > Are you fairly sure it has a size?
> > > > You might try setting it's perferredSize.
> > > >
> > > > > ByteBuffer svgFile //...
> > > > >
> > > > > BufferedInputStream svgFileStream = new BufferedInputStream(new
> > > > > ByteArrayInputStream(svgFile));
> > > > >
> > > > > // Parse the memory buffer
> > > > > String parser = XMLResourceDescriptor.getXMLParserClassName();
> > > > > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > > > > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> > > > >
> > > > > // Build the GVT tree
> > > > > UserAgent userAgent = new UserAgentAdapter();
> > > > > DocumentLoader loader = new DocumentLoader(userAgent);
> > > > > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > > > > ctx.setDynamicState(BridgeContext.DYNAMIC);
> > > >
> > > > You want/need to set this as 'BridgeContext.STATIC'
> > > >
> > > > > GVTBuilder builder = new GVTBuilder();
> > > > > GraphicsNode rootNode = builder.build(ctx, doc);
> > > > >
> > > > > canvas.setGraphicsNode(rootNode);
> > > > >
> > > > >
> > > > > Now, am I missing something? Is the GVT tree building code ok?
> > > >
> > > > Everything looks pretty good to me.
> > > >
> > > > > Another question is, after rendering the document to the
> > JGVTComponent,
> > > > how
> > > > > can I dispose of the DOM?
> > > >
> > > > If you remove all your references to it (i.e. set doc=null)
then
> > > > it should just be collected by the JVM. However as I said text
> > > > currently holds a hard reference into the DOM which will prevent
> > > > the document from really going to GC. I'm looking at ways to
> > > > fix this...
> > > >
> > > > > I never worked with JGVTComponent, so I'm a little lost.
> > > >
> > > > I would suggest creating a small test app so you can
> > > > get the GVT Canvas up and running in isolation (and also I
> > > > can help you get it going).
> > > >
> > > >
> > > >
---------------------------------------------------------------------
> > > > 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
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail:
batik-users-help@xmlgraphics.apache.org
> >
> >
> [attachment "sample.svg" deleted by Thomas E. DeWeese/449433/EKC]
> ---------------------------------------------------------------------
> 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: Rendering with JGVTComponent
Posted by André Ávila <as...@nextech.com.br>.
Hi Thomas,
I'm sending a sample file as you suggested. They are indeed setting the
width, height and viewbox, like you said. Could this be a problem?
----- Original Message -----
From: <th...@kodak.com>
To: <ba...@xmlgraphics.apache.org>
Cc: <ba...@xmlgraphics.apache.org>
Sent: Monday, March 20, 2006 9:33 AM
Subject: Re: Rendering with JGVTComponent
> Hi André,
>
> André Ávila <as...@nextech.com.br> wrote on 03/20/2006 07:23:55 AM:
>
> > It looks like it is a problem with our SVGs. I tried the Batik sample
> files,
> > and they all work fine in my JGVTComponent. Our files don't. Strangely
> > enough, those same files are correctly rendered in a JSVGCanvas.
>
> Do they use Scripting to build the document (based on the
> 'onload' attribute or something)? Do they have width/height
> & viewBox? I'm not sure those will be applied with the JGVTComponent
> (they can be it's just that you will need to provide the viewing
> transform).
>
> > I looked at our files and didn't see anything wrong. I think they are
> not
> > malformed since they work in JSVGCanvas (and Firefox, BTW).
>
> Can you post a small representative example?
>
> > Do you have any clues on what could be the problem? Are there any
> elements
> > that could be causing this behavior?
> >
> > I'm using the latest SVN version (06-03-16).
> >
> > ----- Original Message -----
> > From: <th...@kodak.com>
> > To: <ba...@xmlgraphics.apache.org>
> > Cc: <ba...@xmlgraphics.apache.org>
> > Sent: Sunday, March 19, 2006 3:47 PM
> > Subject: Re: Rendering with JGVTComponent
> >
> >
> > > Hi André,
> > >
> > > André Ávila <as...@nextech.com.br> wrote on 03/19/2006 12:49:01 PM:
> > >
> > > > I'm trying to render a document in a JGVTComponent, but I still get
> a
> > > blank
> > > > screen. The SVG comes from a ByteBuffer. Here we go:
> > > >
> > > >
> > > > JGVTComponent canvas //... part of the GUI
> > >
> > > Are you fairly sure it has a size?
> > > You might try setting it's perferredSize.
> > >
> > > > ByteBuffer svgFile //...
> > > >
> > > > BufferedInputStream svgFileStream = new BufferedInputStream(new
> > > > ByteArrayInputStream(svgFile));
> > > >
> > > > // Parse the memory buffer
> > > > String parser = XMLResourceDescriptor.getXMLParserClassName();
> > > > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > > > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> > > >
> > > > // Build the GVT tree
> > > > UserAgent userAgent = new UserAgentAdapter();
> > > > DocumentLoader loader = new DocumentLoader(userAgent);
> > > > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > > > ctx.setDynamicState(BridgeContext.DYNAMIC);
> > >
> > > You want/need to set this as 'BridgeContext.STATIC'
> > >
> > > > GVTBuilder builder = new GVTBuilder();
> > > > GraphicsNode rootNode = builder.build(ctx, doc);
> > > >
> > > > canvas.setGraphicsNode(rootNode);
> > > >
> > > >
> > > > Now, am I missing something? Is the GVT tree building code ok?
> > >
> > > Everything looks pretty good to me.
> > >
> > > > Another question is, after rendering the document to the
> JGVTComponent,
> > > how
> > > > can I dispose of the DOM?
> > >
> > > If you remove all your references to it (i.e. set doc=null) then
> > > it should just be collected by the JVM. However as I said text
> > > currently holds a hard reference into the DOM which will prevent
> > > the document from really going to GC. I'm looking at ways to
> > > fix this...
> > >
> > > > I never worked with JGVTComponent, so I'm a little lost.
> > >
> > > I would suggest creating a small test app so you can
> > > get the GVT Canvas up and running in isolation (and also I
> > > can help you get it going).
> > >
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: Rendering with JGVTComponent
Posted by th...@kodak.com.
Hi André,
André Ávila <as...@nextech.com.br> wrote on 03/20/2006 07:23:55 AM:
> It looks like it is a problem with our SVGs. I tried the Batik sample
files,
> and they all work fine in my JGVTComponent. Our files don't. Strangely
> enough, those same files are correctly rendered in a JSVGCanvas.
Do they use Scripting to build the document (based on the
'onload' attribute or something)? Do they have width/height
& viewBox? I'm not sure those will be applied with the JGVTComponent
(they can be it's just that you will need to provide the viewing
transform).
> I looked at our files and didn't see anything wrong. I think they are
not
> malformed since they work in JSVGCanvas (and Firefox, BTW).
Can you post a small representative example?
> Do you have any clues on what could be the problem? Are there any
elements
> that could be causing this behavior?
>
> I'm using the latest SVN version (06-03-16).
>
> ----- Original Message -----
> From: <th...@kodak.com>
> To: <ba...@xmlgraphics.apache.org>
> Cc: <ba...@xmlgraphics.apache.org>
> Sent: Sunday, March 19, 2006 3:47 PM
> Subject: Re: Rendering with JGVTComponent
>
>
> > Hi André,
> >
> > André Ávila <as...@nextech.com.br> wrote on 03/19/2006 12:49:01 PM:
> >
> > > I'm trying to render a document in a JGVTComponent, but I still get
a
> > blank
> > > screen. The SVG comes from a ByteBuffer. Here we go:
> > >
> > >
> > > JGVTComponent canvas //... part of the GUI
> >
> > Are you fairly sure it has a size?
> > You might try setting it's perferredSize.
> >
> > > ByteBuffer svgFile //...
> > >
> > > BufferedInputStream svgFileStream = new BufferedInputStream(new
> > > ByteArrayInputStream(svgFile));
> > >
> > > // Parse the memory buffer
> > > String parser = XMLResourceDescriptor.getXMLParserClassName();
> > > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> > >
> > > // Build the GVT tree
> > > UserAgent userAgent = new UserAgentAdapter();
> > > DocumentLoader loader = new DocumentLoader(userAgent);
> > > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > > ctx.setDynamicState(BridgeContext.DYNAMIC);
> >
> > You want/need to set this as 'BridgeContext.STATIC'
> >
> > > GVTBuilder builder = new GVTBuilder();
> > > GraphicsNode rootNode = builder.build(ctx, doc);
> > >
> > > canvas.setGraphicsNode(rootNode);
> > >
> > >
> > > Now, am I missing something? Is the GVT tree building code ok?
> >
> > Everything looks pretty good to me.
> >
> > > Another question is, after rendering the document to the
JGVTComponent,
> > how
> > > can I dispose of the DOM?
> >
> > If you remove all your references to it (i.e. set doc=null) then
> > it should just be collected by the JVM. However as I said text
> > currently holds a hard reference into the DOM which will prevent
> > the document from really going to GC. I'm looking at ways to
> > fix this...
> >
> > > I never worked with JGVTComponent, so I'm a little lost.
> >
> > I would suggest creating a small test app so you can
> > get the GVT Canvas up and running in isolation (and also I
> > can help you get it going).
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: Rendering with JGVTComponent
Posted by André Ávila <as...@nextech.com.br>.
Hi, Thomas.
It looks like it is a problem with our SVGs. I tried the Batik sample files,
and they all work fine in my JGVTComponent. Our files don't. Strangely
enough, those same files are correctly rendered in a JSVGCanvas.
I looked at our files and didn't see anything wrong. I think they are not
malformed since they work in JSVGCanvas (and Firefox, BTW).
Do you have any clues on what could be the problem? Are there any elements
that could be causing this behavior?
I'm using the latest SVN version (06-03-16).
----- Original Message -----
From: <th...@kodak.com>
To: <ba...@xmlgraphics.apache.org>
Cc: <ba...@xmlgraphics.apache.org>
Sent: Sunday, March 19, 2006 3:47 PM
Subject: Re: Rendering with JGVTComponent
> Hi André,
>
> André Ávila <as...@nextech.com.br> wrote on 03/19/2006 12:49:01 PM:
>
> > I'm trying to render a document in a JGVTComponent, but I still get a
> blank
> > screen. The SVG comes from a ByteBuffer. Here we go:
> >
> >
> > JGVTComponent canvas //... part of the GUI
>
> Are you fairly sure it has a size?
> You might try setting it's perferredSize.
>
> > ByteBuffer svgFile //...
> >
> > BufferedInputStream svgFileStream = new BufferedInputStream(new
> > ByteArrayInputStream(svgFile));
> >
> > // Parse the memory buffer
> > String parser = XMLResourceDescriptor.getXMLParserClassName();
> > SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> > SVGDocument doc = f.createSVGDocument(null, svgFileStream);
> >
> > // Build the GVT tree
> > UserAgent userAgent = new UserAgentAdapter();
> > DocumentLoader loader = new DocumentLoader(userAgent);
> > BridgeContext ctx = new BridgeContext(userAgent, loader);
> > ctx.setDynamicState(BridgeContext.DYNAMIC);
>
> You want/need to set this as 'BridgeContext.STATIC'
>
> > GVTBuilder builder = new GVTBuilder();
> > GraphicsNode rootNode = builder.build(ctx, doc);
> >
> > canvas.setGraphicsNode(rootNode);
> >
> >
> > Now, am I missing something? Is the GVT tree building code ok?
>
> Everything looks pretty good to me.
>
> > Another question is, after rendering the document to the JGVTComponent,
> how
> > can I dispose of the DOM?
>
> If you remove all your references to it (i.e. set doc=null) then
> it should just be collected by the JVM. However as I said text
> currently holds a hard reference into the DOM which will prevent
> the document from really going to GC. I'm looking at ways to
> fix this...
>
> > I never worked with JGVTComponent, so I'm a little lost.
>
> I would suggest creating a small test app so you can
> get the GVT Canvas up and running in isolation (and also I
> can help you get it going).
>
>
> ---------------------------------------------------------------------
> 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: Rendering with JGVTComponent
Posted by th...@kodak.com.
Hi André,
André Ávila <as...@nextech.com.br> wrote on 03/19/2006 12:49:01 PM:
> I'm trying to render a document in a JGVTComponent, but I still get a
blank
> screen. The SVG comes from a ByteBuffer. Here we go:
>
>
> JGVTComponent canvas //... part of the GUI
Are you fairly sure it has a size?
You might try setting it's perferredSize.
> ByteBuffer svgFile //...
>
> BufferedInputStream svgFileStream = new BufferedInputStream(new
> ByteArrayInputStream(svgFile));
>
> // Parse the memory buffer
> String parser = XMLResourceDescriptor.getXMLParserClassName();
> SAXSVGDocumentFactory f = new SAXSVGDocumentFactory(parser);
> SVGDocument doc = f.createSVGDocument(null, svgFileStream);
>
> // Build the GVT tree
> UserAgent userAgent = new UserAgentAdapter();
> DocumentLoader loader = new DocumentLoader(userAgent);
> BridgeContext ctx = new BridgeContext(userAgent, loader);
> ctx.setDynamicState(BridgeContext.DYNAMIC);
You want/need to set this as 'BridgeContext.STATIC'
> GVTBuilder builder = new GVTBuilder();
> GraphicsNode rootNode = builder.build(ctx, doc);
>
> canvas.setGraphicsNode(rootNode);
>
>
> Now, am I missing something? Is the GVT tree building code ok?
Everything looks pretty good to me.
> Another question is, after rendering the document to the JGVTComponent,
how
> can I dispose of the DOM?
If you remove all your references to it (i.e. set doc=null) then
it should just be collected by the JVM. However as I said text
currently holds a hard reference into the DOM which will prevent
the document from really going to GC. I'm looking at ways to
fix this...
> I never worked with JGVTComponent, so I'm a little lost.
I would suggest creating a small test app so you can
get the GVT Canvas up and running in isolation (and also I
can help you get it going).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org