6

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 :-)

Dave Carpeneto
  • 1,042
  • 2
  • 12
  • 23

1 Answers1

4

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
  • 10,269
  • 5
  • 42
  • 57
  • my only problem is that I cannot buffer the entire image - it's too huge. Which means I need to keep buffered sections as they're drawn, check for coverage when I'm called to paint() & sew them together as needed. I guess I'll give it a shot, but I'll hold off to see if anyone else has any ideas – Dave Carpeneto Feb 19 '09 at 21:20
  • 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 Feb 20 '09 at 03:58
  • 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 Feb 20 '09 at 13:39
  • 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 Feb 20 '09 at 16:56