Humm... Now we found another issue. When we scroll quickly, it doesn't paint everything. We tried it on the sample (batikBatik.svg) and got the same results. We zoomed in quite a bit so we had a lot of room to scroll and then scrolled around. It is pretty sporatic...it just seems to randomly not paint certain sections. Is this a known behaviour? Is there something we can do about it?
Hi Mark,
This sounds like an 'old' problem, where tiles that were abandonded because a new rendering was requested. I think I've found a possible hole where uncomputed tiles could end up in the tilestore. I'll deliver this to CVS today. If you want to try the fix yourself:
Index: sources/org/apache/batik/ext/awt/image/rendered/AbstractTiledRed.java
===================================================================
RCS file:
/home/cvs/xml-batik/sources/org/apache/batik/ext/awt/image/rendered/AbstractTiledRed.java,v
retrieving revision 1.16
diff -w -u -c -5 -r1.16 AbstractTiledRed.java
cvs server: conflicting specifications of output style
*** sources/org/apache/batik/ext/awt/image/rendered/AbstractTiledRed.java 8 Aug
2003 11:39:07 -0000 1.16
--- sources/org/apache/batik/ext/awt/image/rendered/AbstractTiledRed.java 13 Aug
2003 10:24:14 -0000
***************
*** 461,470 ****
--- 461,473 ----
drawBlock(block, wr);
// Exception e= new Exception("Foo");
// e.printStackTrace();
}+ if (Thread.currentThread().isInterrupted())
+ return;
+
idx = 0;
// Fill in the ones that weren't in the cache.
for (ty=ty0; ty<=ty1; ty++) {for (tx=tx0; tx<=tx1; tx++) {
-----Original Message----- From: Mark Claassen [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 11:38 AM To: 'Batik Users' Subject: RE: Lazy rendering and zoom
We found the scrollable class you were referring to and it seems to be exactly what we needed!
-----Original Message----- From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 10:14 AM To: Batik Users Subject: Re: Lazy rendering and zoom
Mark Claassen wrote:
Thanks for all your help. I believe, though, that I
didn't explain
our main reason for messing with this.
We were hoping to create a Component so that all the
panning could be
done via the scroll bars, and not the arrow keys. The
default zooming
behaviour just renders a piece of the image inside a Component. Depending on how this is used, you might be able to see the whole section, or have scroll bars which can be used to see the
section. We
were wanting to have the scroll bars always set up so that
the whole
document, regardless of zoom, could be navigated to with
the scroll
bars.
The first way that came to mind was just to make the
canvas bigger,
and render the whole image. This, however, took too much memory.
Ok, I see the problem now. We were using getSize() when we should generally use getVisibleRect() to get the area we are actually going to display (and hence the size of the offscreen buffers we should create). I'm in the processes of fixing this.
The next way I thought we could do this would be to make
the canvas as
big as we need for the whole image, but just paint the
portion of the
canvas that is currently being viewed in the scroll pane.
Is there a way in Batik that I can accomplish this through
the API you
mentioned?
You may also want to subclass JSVGCanvas and implement the scrollable interface. Jan Lolling has posted code to do this several times. As long as you do the scrolling by adjusting the rendering transform the tile caching will kick in.
-----Original Message----- From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 12, 2003 4:46 AM To: Batik Users Subject: Re: Lazy rendering and zoom
Hi Mark,
Mark Claassen wrote:
Thanks for the reply.
Ok, so here is our theory: 1) Using the SVG view box and the scale factor, figure how
many tiles
(at say 100 X 100) will fit into the image. 2) Create a JSVGComponent (workingComp) and set the
preferred size to
be the size of our tiles (100 X 100) 3) Set the rendering transform of workingComp to have the
scale factor
we want
The point of my message was that if you zoom the
canvas with a
static document it will automatically tile the image for you. Try
it, bring up an image with a really complex background (try
samples/batikBatik.svg) Zoom in a bunch Pan right notice it takes a second or two to update, Pan back left notice it repaints immediately.
The biggest problem with the current scheme is that the tile
cache is extrememly limited in size it keeps ~50 128x128 tiles in memory (around 4MB - which is like one screenful of data these days). This can be adjusted by making calls to:
org.apache.batik.ext.awt.image.rendered.TileCache.setSize(in sz);
The cache actually does use SoftReferences to try
and reclaim
tiles that age out of the cache but these are generally pretty
quickly reclaimed. The number you provide is the number
of tiles it
will hold hard references to.
--- In our paint method for our JComponent (myComp), we will
paint the
tiles that are visible in our scrollpane.
For each visible tile 4) translate the rendering transform so that the part
of the tile we
want is on the workingComp 5) Draw this to a buffered image and keep it. 6) repaint this tile on myComp
Does this sound OK? Are there any obvious pitfalls or
performance
issues that might make this not a practical solution?
The current system goes to great lengths to rendering large
'patches' of the image at once and then split the data out into tiles after the fact, this is significantly more efficent then rendering each individual tile.
-----Original Message----- From: Thomas DeWeese [mailto:[EMAIL PROTECTED] Sent: Friday, August 08, 2003 6:29 PM To: Batik Users Subject: Re: Lazy rendering and zoom
Mark Claassen wrote:
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; canvas.setPreferredSize(d) canvas.revalidate();
Is there a better way?
Yes change the rendering transform, take a look at Zoom(In|Out)?Action in JSVGCanvas.java you are actually
doubling the
size of the 'visible' canvas so it creates an offscreen
that size.
-----Original Message----- From: Thomas DeWeese [mailto:[EMAIL PROTECTED] 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: [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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
