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. 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? Mark > -----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]
