views:

764

answers:

2

I've got a routine that paints an insanely large graph inside a scroll pane. It's too big to paint before adding to the scrollpane - the menory requirements would be several gigs.

Because of the size of the graph I'm rendering the chart within the paint method of the scrollpane's child. Which works out well, however I'm noticing that every time a scrollbar is moved my paint routine is called twice - once with a clipping rect equal to the uncovered area scrolled to, and a second time with the clipping rect equal to the viewport's dimensions.

For example if my viewport is 245x195 & I scroll down by 3 pixels my paint routine gets called with g.getClipBounds() set as follows:

java.awt.Rectangle[x=0,y=195,width=245,height=3]
java.awt.Rectangle[x=0,y=3,width=245,height=195]

... because I render within the paint routine this is causing flicker (I do my calcs as fast as I can, but there is a wee bit of a delay I guess). Questions:

  1. Does anyone know how to prevent the 2nd paint call? This is plain-jane JScrollPane stuff I'm doing here - I have a component, I add it to the scrollpane, I add the scrollpane to a parent component. You can see this behavior even in the first image scrolling demo @ the swing tutorial.

  2. If the answer to #1 is 'nope': can anyone think of a good way to deal with this ? Should I paint to some sort of image buffer, track recent paint calls & copy the image where possible ? I cannot imagine this being much faster than re-rendering, but any insight appreciated :-)

+2  A: 

I've ran into this issue in the .NET world. Double buffering should solve your problem.

If you're rendering directly onto a surface that is shown on the screen, you have no control over when the "showing" actually happens. What typically happens is: you start rendering, the not-yet-finished image is being displayed on the screen, you finish rendering, and then that is finally shown on the screen.

If you begin your rendering logic by clearing to a background color, then this will appear like a flash. Double buffering prevents this because it's always displaying from a completed render. The worst that could happen is slight 'tearing' but that's only noticeable in quickly changing animations.

Even if you only want to render part of a gigantic image, you can still use this technique. Simply render what you need onto an off-screen surface (which is the size of the visible portion you want). And then when you're done, draw the entire image onto your display surface in one fell swoop.

colithium
Dave Carpeneto
Well, double buffering can still come into play. Simply render what you need to on an off-screen surface (the size of the visible portion). And then when you're done, draw the entire image onto your display surface in one fell swoop.
colithium
actually, this works. Thanks :-) Scrolling is a wee bit slower, but the flicker is gone. Sorry I didn't get it @ first - my stupidity was no match for your perseverance ;-)
Dave Carpeneto
Oh no worries. I actually didn't understand that what you were drawing was that huge until your comment. The only thing to do to make it quicker is to improve your drawing logic, but there's always going to be some delay. Good luck.
colithium
A: 

I'm trying to do some custom drawing similar to what you're describing, when I implement scrollable no drawing happens, but when scrollable is not implemented the drawing is correct and the scroll bars show up. Could you please explain how you:

I'm rendering the chart within the paint method of the scrollpane's child. Which works out well

Thanks