There is a flush primitive which should be used.  

http://isqueak.org/ioForceDisplayUpdate

Normally that is called by morphic. In cases of bad code design the osx and iOS version schedule a flush if needbe every n milliseconds. I think the windows version just respects the flush  The x11 flavors just flush on each draw which make it slower 

Sent from my iPhone

On Jan 30, 2014, at 2:24 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:




On Thu, Jan 30, 2014 at 11:20 AM, Bob Arning <arning315@comcast.net> wrote:

Given that it is a simulation popping up the menu, how fast is it reasonable to expect? What is your normal simulated bytecodes/sec? How many bytecodes executed in that 5 minutes? Perhaps more importantly, how many simulated screen redraws in that interval? How expensive are these?

Oh, good point!  I think the simulator restricts redraws to every few thousand bytecodes.  It would be much more responsive if somehow the simulator could update the screen whenever the bitblt primitive affects the screen.
 

Cheers,
Bob

On 1/30/14 1:50 PM, gettimothy wrote:
       Event processing is dog slow. Be prepared to wait 5 minutes for the menu to pop up.
      ...

       How do I make this responsive and useful?




--
best,
Eliot