Snippit from an email sent by Steve:

----------------------------------
Hi Folks,

I was talking to some of you earlier today about the possibility that 
JViewport's backing store isn't working as advertised.  I've been doing a 
little expirementing and come to the conclusion that something seems to have 
broken.  

My first test was to modify Tina Su's Table SwingMark test to toggle the 
backing store.  I didn't find much difference there.  I realized that there 
was so much baggage with that test (which involves a lot more that scrolling) 
that perhaps I should create a leaner focused test.  You can find it at:

/home/wilsonsd/SwingMarks/TableScrollTest

You can run the test in one of two ways:

java TableScrollTest   (this leaves the backing store on)
java TableScrollTest -bs=off (this turns it off)

Please feel free to check my code and make sure I deactivated it correctly.  
My first few trys were tripped up by the fact that JTable seems to turn it on 
at addNotify time.  I think I've got it now, but please check to be sure.

In addition to tracking execution time, which is always tough, I added checks 
to track the number of times paint is called (for the JTable and the 
Renderer).

This test creates a table with 10 columns and 1000 rows.  The test scrolls 
though ~200 rows one row at a time.

The results from running these (with JDK 1.1.7 are as follows):

Time: ~16 seconds for both (within 0.1 seconds)
JTable Repaints: 189
Renderer Repaints: 45,360

Now, those numbers might look funny, but I have found there is a pattern.  
When the table comes up it is showing 10 columns and 24 rows by default.

10 cols * 24 rows * 189 paints = 45,360 render paints

This seems to show that every time the JTable is asked to paint, the renderer 
is called for each visible cell in the table.  It seems that the point of the 
backing store is that it should only be called for newly exposed cells, which 
means it should be something more like 1,890 times (10 cols * 189 newly 
exposed rows).  I would think this should give us a significant speed increase 
if we could get to that point.
--------------------------------
Reply from Scott:

Yep, it would appear that any paints done via scrollRectToVisible will 
not use the backing store, regardless of what it is set to.
A boolean is maintained in JViewport, scrollUnderway, to indicate if a 
scroll is underway so that paint will try and use the backing
store. scrollRectToVisible will always set this to false after calling 
setViewPosition (setViewPosition sets it to true), which results in
the backing store never being used:( Most of the time the user will
click and drag the scrollbar, which only results in setViewPosition
being called, which sets scrollUnderway to true, and results in the
backing store being used... We probably haven't heard too much about
this since it only happens when scrollRectToVisible is programaticly
invoked.