xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject Re: Using multiple JSVGCanvas' in a CardLayout - Heap Overflow
Date Mon, 05 May 2008 12:05:33 GMT
Hi Sean,

"Sean Hanlon" <wanderer3791@gmail.com> 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 <tech@robertjdavis.co.uk> 
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: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Mime
View raw message