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: <[EMAIL PROTECTED]> To: <[email protected]> Cc: <[email protected]> Sent: Tuesday, March 21, 2006 11:21 PM Subject: Re: Rendering with JGVTComponent > Hi Andre, > > André Ávila <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> > > To: <[email protected]> > > Cc: <[email protected]> > > Sent: Monday, March 20, 2006 10:30 AM > > Subject: Re: Rendering with JGVTComponent > > > > > > > Hi Andre, > > > > > > André Ávila <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> > > > > To: <[email protected]> > > > > Cc: <[email protected]> > > > > Sent: Monday, March 20, 2006 9:33 AM > > > > Subject: Re: Rendering with JGVTComponent > > > > > > > > > > > > > Hi André, > > > > > > > > > > André Ávila <[EMAIL PROTECTED]> 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: <[EMAIL PROTECTED]> > > > > > > To: <[email protected]> > > > > > > Cc: <[email protected]> > > > > > > Sent: Sunday, March 19, 2006 3:47 PM > > > > > > Subject: Re: Rendering with JGVTComponent > > > > > > > > > > > > > > > > > > > Hi André, > > > > > > > > > > > > > > André Ávila <[EMAIL PROTECTED]> 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: > > > [EMAIL PROTECTED] > > > > > > > For additional commands, e-mail: > > > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > [attachment "sample.svg" deleted by Thomas E. DeWeese/449433/EKC] > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
