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]
