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