Build : 'G' ('F' the same but UNable to regress D, E, .... 'A' however ok.)
app : Java2Demo.jar
OS : 95/98 (NT seems ok, does not seem DD/GDI related, tried noddraw)

Specifically on the J2D lightweight Swing JMenus the actual painting of the pulldown part of the menu slow down dramatically. In build 'A' and in cricket, it was on par with 1.2fcs. But somewhere between A and F the painting of the pulldown has deteriorated to the point where even on a PII350 machine it takes a full 30secs+ to draw or sometimes minutes if even at all!

SwingSet demo where it's heavyweight components don't exhibit this problem.

================================================
I am reopening this bug as this bug is reproducible in the latest builds of jdk (77,78,79,80,81). This is occurring in Sparc and IA Solaris and Red hat linux 7.1. When 2 demos(Java2Demo) is opened and is kept one above another and the window is moved, it takes a long time to repaint the other window which is very much visible

===================================================================

I am closing this again. It is certainly possible to slow down a program by
using up all the cpu, or other resources. It is also possible to starve low-priority threads by posting massive numbers of higher-priority events.
This is possible on any platform, in any programming language.

The problem added to this bug report about the Java2Demo occurs because that
demo stresses the capabilities of most computers to their limit. It isn't a
bug in Java.

The original problem this bug was filed about was a serious performance
regression in kestrel. That problem has not resurfaced.

###@###.### 2001-11-19