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