Switch to TestRunnerPlus (part of ToolBuilder examples). Or more 
accurately: Switch to any TestRunner which does not run tests in 
concurrent processes, thereby creating unforeseen interactions with the 
primary UI process, thereby at some point having multiple UI processes 
running thereby screwing up the display. It's amazing to me how people 
can deal with the default TestRunner at all given how flawed it is.

Cheers,
   - Andreas

Avi Bryant wrote:
> On 6/21/05, Alain Fischer <mailinglist.fischer at bluewin.ch> wrote:
> 
>>When you launch the debugger from TestRunner by clicking on an error
>>list item,
>>the PreDebugWindow is very slow to be drawn and it seem that each part
>>of the
>>window and invalidated area are drawn and flushed to the Display.
>>The back buffering (draw all parts the flush the affected area to the
>>Display)
>>of the Display seem bypassed.
>>
>>Other one has seen this ? or just me ?
> 
> 
> Yes, I see this all the time - not just when using the TestRunner (and
> not always then, it doesn't seem  to be very consistent).  It's
> probably my number one frustration when developing in Squeak these
> days.  The only workaround I've found is to simply not have many
> system windows open at any one time... anyone have a fix for this?
> 
> Avi
> 
>