java.awt.list & java.awt,Component recurse

[Dan McGuirk]

On Fri, 4 Dec 1998 peter at transvirtual.com wrote:
> Oh lord - a proof for my theory that everything ill that can be thought out
> will eventually be done. It's easy to make Component.repaint(..) async (via
> the queue, like it is done for a non-zero repaint delay). But this is
> another way to slow down the system. And the spec just says it should "call
> update() as soon as possible" - which can also mean immediate. Looks rather
> like we need another fix to make a bug work..

If Component.repaint() were called via the event queue instead of
directly, the stack would not overflow, but the program would still wind
up in an infinite loop of repaints, wouldn't it?  For this specific
example I think it would be enough if setBounds() checked whether its new
bounds were any different from the old ones, and didn't request a paint
unless they were.  The problem is that for other calls that change
component state it may not be so easy to determine whether the change has
a visual effect (and therefore requires a repaint) or not.  I think in
general it should be considered bad practice to change component state
from inside a paint() method...