Mark Claassen wrote:
I managed to get the viewport to be the correct size, for the scrolling
and zooming to work correctly, but the whenever the canvas is changed
the document is zoomed again.  Can this be turned off?

However, I don't think I have the the 'fix', and this might just fix the
issue for me.  Can you give me a diff so I can change it see, or is it
too big a fix.

If you are using Zach's version of a scrolling region you don't need my fix. His code sets up the JSVGCanvas to be the visible size and then passes it translates as the scroll bars are moved. This is arguably the cleanest solution but means that all the behaviour of JSVGScrollPane needs to be reimplemented. You should probably look at his updated version.


Thanks, Mark


-----Original Message-----
From: Mark Claassen [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 2:29 PM
To: 'Batik Users'
Subject: RE: Lazy rendering and zoom



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]



Reply via email to