xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Claassen <...@donnell.com>
Subject RE: Lazy rendering and zoom
Date Fri, 08 Aug 2003 18:20:52 GMT
Thanks for the reply.

As it turns out, we are using a static document already.  We went ahead
and actually set the state to be static, but we still get the memory
problem if we zoom enough.  (It seems that we are now able to zoom a bit
more, although this may just be a coincidence.)  From your description,
we thought it was futile to override the createImageRenderer method as
this point.

It seems to me that if the tiles are rendered lazily, we could zoom
indefinitely and use a relatively constant amount of memory.  Also, we
have never noticed the document being painted as we scroll.  If the
tiles truley were rendered lazily, I would except to see this.

Maybe we are just doing something wrong.  We weren't quite sure how to
get the zoom we wanted using the API directly, so we resize the canvas
to zoom.  To zoom 2X, we:

Dimension d = canvas.getSize();
d.width = d.width * 2;
d.height = d. height * 2;

Is there a better way?

> -----Original Message-----
> From: Thomas DeWeese [mailto:Thomas.DeWeese@Kodak.com] 
> Sent: Friday, August 08, 2003 12:10 PM
> To: Batik Users
> Subject: Re: Lazy rendering and zoom
> Mark Claassen wrote:
> > I noticed there is a setProgressivePaint(boolean) method in 
> > JGVTComponent.  This seems to display items on the canvas 
> as they are 
> > rendered, and not just display the whole document at once.
> > 
> > What I was wondering was if there is an option that goes a step 
> > further, and would restrict rendering to just viewable 
> area.  This is 
> > a common thing in Swing, where, for instance, the rows of a 
> table that 
> > are not currently visible in a JScrollPane are never rendered.
> > 
> > The default zooming behaviour in Batik seems to render a portion of 
> > the document while not changing the canvas size.  We would like to 
> > change the canvas size, so that the we can pan to see any 
> part of the 
> > document we need simply by moving the scrollbars.  
> Unfortunately, this 
> > causes OutOfMemory errors when the zoom factor gets large.
> > 
> > I know we can increase the JVM heap size, but this can only 
> go so far. 
> > What I was hoping for was something in the JSVGCanvas that 
> would draw 
> > just a portion of the document on the canvas, and then when 
> a scroll 
> > occurred, it would noticed that this area had not been rendered and 
> > draw that.  One could even go so far as to anticipate the 
> loading of 
> > sections and use SortReferences to hold now longer visible sections.
> > 
> > Is there anything like this, or any plans to include something like 
> > this?
> Hi Mark,
>      This is already done for Static Documents.  The Static 
> Renderer keeps a tiled view of the image and when translates 
> happen it tries to populate the new view from the stored 
> tiles.  This is generally not done for dynamic documents as 
> maintaining the tile store is expensive for many small 
> changes (the system would widens rendering requests to tile 
> boundries) also there were a few bugs in what I will call odd 
> cases (the size/location of the root SVG changing). However 
> depending on your context this still might be a win for your 
> case.  It is pretty easy to change this by overiding the 
> following method in batik.swing.svg.JSVGComponent:
>      protected ImageRenderer createImageRenderer() {
>          if (isDynamicDocument) {
>              return rendererFactory.createDynamicImageRenderer();
>          } else {
>              return rendererFactory.createStaticImageRenderer();
>          }
>      }
>     So it always returns a static ImageRenderer.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org

To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org

View raw message