Hi Sean,
"Sean Hanlon" <[EMAIL PROTECTED]> wrote on 05/05/2008 09:27:16 AM:
> I have a single canvas that, based on user selection loads the
> appropriate svg file (using the JSVGCanvas' loadSVGDocument). This
> keeps the memory footprint pretty small, and the file IO isn't
noticeable.
Good.
> Is there a way to load an SVGDocument directly from a String? My svg
> files are small enough that I can actually assign them to a string
> variable. Then, when it's time to load, no more disk IO.
The Canvas won't take a string but it will take a DOM Document.
You can easily turn a string into a Document with our
batik.dom.svg.SVGDocumentFactory using:
SVGDocument createSVGDocument(String uri, Reader r)
We use URI to resolve any relative references (images etc,
which I'm guessing you don't have). The reader can be a
simple StringReader. You might also consider reading all of
your documents into SVGDocuments and then just calling
'setDocument' on the canvas. That way you save the parsing
step (which while not large is still a noticable part of the
work of going from XML content to first display).
> Luckily, the svg files aren't going to be changing once the
> application goes to production, so a static svg file approach
> has merit.
You might consider simply bundling the files into your JAR
file as this can simplify distribution and yet still makes it
fairly easy to modify the files during development (where you
can set the classpath to include the files on disk).
> On Mon, May 5, 2008 at 8:05 AM, <[EMAIL PROTECTED]> wrote:
>
> Hi Sean,
>
> "Sean Hanlon" <[EMAIL PROTECTED]> wrote on 05/02/2008 11:36:49 AM:
>
>
> > I tried increasing the heap to 128 MB and that has alleviated the
> > heap problem. I still can't get my head around how small resizes are
> > no problem, but a maximize overflows the heap. I'd like to get to
> > the bottom of that for peace of mind!
>
> The Canvas keeps an offscreen image (usually two actually so
> we draw to one while we show the other). So a larger canvas will
> require more memory. Also on resize the canvas will try and redraw
> everything for the new canvas size. Batik also tries to make use
> of soft references for 'intermediate' objects, so my guess is that
> on maximize between the new larger offscreen images, and all of
> the canvas's redrawing at once it's enough to put you over the edge.
>
> I understand that most of the above occurs for small resizes
> but if you are near the edge I can see that the maximize adds
> just enough extra stuff to kill your application.
>
> > Is there a more efficient way to display multiple canvases that I
> > haven't considered?
> Well the most obvious is the one below, load them when they are
> needed. You could also potentially load one document that contains
> all three and rather than loading a full new document simply adjust
> visibility/display to show what you want.
>
> > I considered loading the canvas when the user selects that section
> > (kind of a lazy load), but then the file IO might get dicey and it
> > seems foolish to continually load the document if a user toggles
> > back and forth between sections.
> I don't know how many tabs you had but you could also keep two
> canvas's so if the user is switching back and forth they don't have
> to wait for the load.
>
> > I am going to try and explore why the JSVGCanvas isn't drawn full
> > size when added to a JPanel after the JPanel has been
> > initialization. If I can solve that, I can avoid the CardLayout
> > entirely. Any insight on that are appreciated.
> >
> > So (very rough):
> > JPanel panel = new JPanel(new BorderLayout());
> > //add panel to JFrame
> >
> > //when a user makes a selection add JSVGCanvas (which was preloaded
> > and stored in an ArrayList but not added to any Swing components)
> > panel.add(canvases.get(i), BorderLayout.CENTER);
> > panel.invalidate();
> The problem may be that the viewbox to screen transform is set
> when the canvas is loaded. So if it's not in the swing hierarchy
> when the document is loaded it won't know what it's size is.
>
> If you run the code:
> if (computeRenderingTransform())
> scheduleGVTRendering();
>
> It should fix it's self. The easiest way to do that is
> to call (there should be a better way...):
> canvas.setFragmentIdentifier(canvas.getFragmentIdentifier);
>
> > The behavior this is producing is the canvas is drawn in the lower
> > right corner of the panel and is not resized to fill the available
> > space (as it does when inside a CardLayout). Seems odd, I hope I
> > just missed something simple.
> You may also need to call 'panel.pack()' so it updates the sizes of
> all it's children (which might also fix the drawing problem). Normally
> if the viewbox transform isn't right it will draw in the upper left
> corner not the bottom right, so it may be that the canvas isn't resizing
> to fill the panel (which is a swing problem).
>
> > On Fri, May 2, 2008 at 11:15 AM, Rob Davis-5 <[EMAIL PROTECTED]
> > wrote:
> >
> >
> >
> > Sean Hanlon wrote:
> > >
> > > I tried
> > > removing the CardLayout and, on user selection, add the JSVGCanvas
to the
> > > panel directly (so on resizes only the currently visible canvas is
> > > resized).
> > > The problem I saw with this approach is that the JSVGCanvas wasn't
scaled
> > > and didn't maximize the display area as it does when I load them all
at
> > > initialization in the CardLayout.
> > >
> > >
>
> > Guess you need to try and see how the initialisation of a JSVGCanvas
within
> > CardLayout is different when compared with initialising JSVGCanvas
outside
> > of it as you had attempted.
> >
> > Maybe CardLayout is registered with the Java windowing system so gets
> > notified of a resize/maximise, and, when a JSVGCanvas is not
initialised
> > within it then it doesnt know that it should maximise. Try to check if
your
> > JSVGCanvas's are correctly hooked up to be made aware of any such
events at
> > the appropriate time.
> >
> > If it were me I'd be stepping through the batik source on Eclipse
debugger
> > to see what happens.
> >
> > Another thought is, does it matter, if you can resolve it by
increasing the
> > heap. Memory is quite cheap. I'd be more concerned about how fast it
ran
> > than memory usage. How much more do you need to increase the heap by?
A lot?
> > Or a little?
> >
> >
> >
> > --
> > View this message in context: http://www.nabble.com/Using-multiple-
> > JSVGCanvas%27-in-a-CardLayout---Heap-Overflow-tp17018867p17021573.html
> > Sent from the Batik - Users mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail:
[EMAIL PROTECTED]
