Thanks for the in-depth reply! I ended up finding a work-around:
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. 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. Luckily, the svg files aren't going to be changing once the application goes to production, so a static svg file approach has merit. Thanks again. -S 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] >
