Thanks, I will work with it. I don't think the 'fix' you mentioned the other day is the issue. I am using the distribution build of batik 1.5. I downloaded this a while ago. I thought you just made the fix last week.
Mark > -----Original Message----- > From: Thomas DeWeese [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 14, 2003 2:22 PM > To: Batik Users > Subject: Re: Lazy rendering and zoom > > > Mark Claassen wrote: > > We finally got everything pretty much working, thanks > largely to your > > (Thomas DeWeese's) help. > > > > We have one more issue that I am having trouble solving. > Here is the > > setup: > > > > (Since the document is so big, I cannot get the entire vertical > > dimension on my screen so my example is dealing with the problem in > > the horizontal dimension. It seems likely that this would > happen in > > the vertical dimension as well, but I have not tried this with a > > different document yet.) > > Ok, so this is caused by my 'fix' of using the visible > bounds (which you need otherwise when you zoom in it will > still take lots of memory). In the case you describe the > visible bounds change without causing a repaint. > Unfortunately this is not going to be trivial to fix, and I > can't really do it since I don't have the scrolling code. > > A quick sketch: > > JGVTComponent.paintComponent needs to account for > the visibleRect x/y used for the last GVT rendering when > drawing it's image (append a translate transform to the > graphics before the paintingTransform). > > You need to register a ChangeListener on the JViewport > so you can schedule a GVT rendering (just call > scheduleGVTRendering) when the viewport size or location changes. > > I think that will do it, but this is getting complex and > I would expect that I am missing something. > > > o Display the document (745 X 1246) in a window with the > ScrollCanvas. > > o It is irrelevant if the document is entirely visible or not in > > either dimension initially. o Zoom in slightly. (Like 105% > of what it > > was) o Expand the visible area of the window (if necessary) > to see the > > whole document. > > o The document is now chopped off on the right, seemingly > being clipped > > at the SVG document's unscaled size > > o Now shrink the window, the scroll bars act appropriately > and seem to > > have the correct bounds > > o Without scrolling, a return my window to its original size. The > > document is chopped as before > > o Shrink the window again > > o Scroll horizontally, The whole document can be viewed. > > o Enlarge the window to see the whole document, and it is > chopped off > > again. > > o Vertical scrolling works and as no affect on the chopped regions. > > > > > > If I first zoom to 80% and then to 85%, it works correctly. > Not until > > I get above 100% do I have the problem. Where should I > look to find > > and fix this problem. The scroll canvas appears to be doing > > everything correctly as far as I can tell. > > > > Also, as I was looking around I noticed this in GVTComponent: > > > > public void setGraphicsNode(GraphicsNode gn) { > > setGraphicsNode(gn, true); > > initialTransform = new AffineTransform(); > > updateRenderingTransform(); > > setRenderingTransform(initialTransform, true); > > } > > > > Is this supposed to be: > > > > public void setGraphicsNode(GraphicsNode gn) { > > setGraphicsNode(gn, true); > > initialTransform = new AffineTransform(); > > if (updateRenderingTransform()) > > setRenderingTransform(initialTransform, true); > > } > > No when you set a graphics node you always want to do > a new rendering (not just if the rendering transform hasn't changed). > > > > > --------------------------------------------------------------------- > 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]
