Do you mean a property sheet tab in the component inspector? Don't you
mean the component palette?

Sorry, I shouldn't file bugs at 7 in the morning after staying up all
night.  Yes, I mean the component palette.

Ok, the repainting/resizing is visible at the first sight, I've
already noticed it. I'll look at it.

Seems to be a layout problem - at least on aqua, each one paints first
with a scrollbar, then the scrollbar disappears.  Maybe you're
displaying it before it is populated or you change the layout manager
after it's visible?

This bug causes regression reported in automated tests for form opening.

Tim's contrib/paintcatcher module reports a lot of events in EQ
related to component pallete during form opening like these(more
precisely at the moment whet it looks to be done but is repainting
some parts):
1488:1078315239504:addDirtyRegion 0,0,24,23 null "null"
(javax.swing.JToggleButton)
1489:1078315239504:addDirtyRegion 0,0,24,23 javax.swing.JToolBar@21015596
1490:1078315239514:addDirtyRegion 0,0,24,23 null "null"
(javax.swing.JToggleButton)
1491:1078315239514:addInvalidComponent null "null"
(javax.swing.JToggleButton)

It might be interesting to set all of the JButtons to use MetalButtonUI and see if the 
regression on XP goes away.  If it is the the UI's scaling of the background bitmap, that 
would prove it.

Note, re paintcatcher, the interesting thing is how many times the regions are actually 
painted - adding invalid regions is fine, but add-paint-add-paint is expensive.

It seems to be a general problem of JLists with HORIZONTAL_WRAP.
When the surrounding JScrollPane creates its layout (e.g. determines
whether to display scrollbars etc.) it asks the list for its
preferred size. Unfortunately the preferred size of such a list
is not defined (the preferred height depends on the prescribed
width) therefore the list simply attempts to place all items
vertically => the resulting preferred height is very big =>
scrollpane displays the scrollbar.

When the list is painted (for the first time) it checks whether
its width is equal to the width for which its layout was calculated.
Unfortunately this is not the case because the width of the interior
of the scrollpane (with scrollbar) was assigned to it =>
it invalidates itself, but finishes incorrect painting.

New layout is then created for the assigned width => the height
of the list is smaller and the scrollbar is not necessary =>
the width of the list is changed again => third layout => third
repaint.

Any idea what can be done to avoid this ugly behaviour?

Problem of a JList with HORIZONTAL_WRAP.

What about your own smarter component/layout with better algorithm for
computing preffered size.

Or if you really think that this should be fixed in Swing than file a
bug against JDK.

Then please file a jdk bug and note the bug number here before closing

IMHO this is a problem of the JList with HORIZONTAL_WRAP,
but I don't think that it can be resolved in the JDK itself.
(I closed this issue previously because otherwise
I wouldn't obtain your feedback ;-))

The problem is that such a list doesn't fit well into
the normal layout management process - getPreferredSize()
method doesn't have a good sense for it. Unfortunately
the standard JScrollPane depends on that method.

Because noone has a better idea I decided to fix that
by a special layout manager assigned to the JScrollPane.
This layout manager knows that the only component
in the JScrollPane's view is our list and attempts
to resize it correctly => the flashing scrollbar
should disappear => number of repaints decreases.

Verified