<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'>Thank you all for your input. Very useful and appreciated.<br><br>Below are your recommendations/comments (in <b>bold</b>)&nbsp; as I have summarized them.<br>My notes to myself on your recommendations/comments are <i>italicized</i>.<br><br>FWIW, my plan is to attempt the Semaphore route per Henrik first, followed by the optimizations suggested by John, Bob and Eliot If I hit the wall on that, try the Morphic approach per Bert's recommendation followed by the optimizations.<br><br><br><b>Check out Pharo InputEventFetcher (Henrik)</b><br><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There's already such a Semaphore operating across the VM/image divide, set by primitive 93.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; You can see an example of how to do an event listener using that in a Pharo images InputEventFetcher ;)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i> Awesome. Thank you so much.</i><br>&nbsp;&nbsp;&nbsp;&nbsp; <br>f<b>iltering out MouseOver events would cut down on the response time? (Henrik)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>do this first as it is an easy implement in EventSensor.</i><br><br><b>Event translation needed? (Henrik)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i> I don't know. My hunch is that it will need to be translated. Translation should be straight-forward when/if I decide to implement it.</i><br><br><b>Use regular Morphic Event processing (Bert)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i>&nbsp; ok, aren't&nbsp; Morphic events constrained to flow along the Morphic component tree ? (Contrasted with the AXAnnouncements framework where one can "Announcer annouce" an event)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If so, that would imply sub-classing the ImageMorph that the Simulator paints the world on where I can implement the forwarding/filtering/translation functionality. Bear in mind, I am a rookie at all but Seaside dev (and I am rusty at that (: )<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If Morphic events are not constrained to flow along the Morphic tree, where is an example of a "Morphic event broadcast" I can forward to the Simulator?</i><br><br><b>Flush Primitive investigate at http://isqueak.org/ioForceDisplayUpdate&nbsp; (John M.)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> 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.</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i> curious what triggers that "need be"</i><br><b>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The x11 flavors just flush on each draw which make it slower </b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>Very informative&nbsp; maybe I could toggle the flush rate on Morphic "focus" or mouseIn/mouseOut events. If I go non-morphic route, how to do this...hmmm<br></i><br><b>It would be much more responsive if somehow the simulator could update the screen whenever the bitblt primitive affects the screen. (Eliot)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>John M. provides the roadmap for this above.</i><br><br><b>Ditch the change to EventSensor (Eliot)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> make the change self-contained by trying to confine the set-up of the plumbing to openAsMorph?</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<i> Yes. The only "Morphic"&nbsp; avenue I see is subclassing ImageMorph. If it's Henrik's listener approach, then definitely yes (to self: consider separation of concerns after it works).<br></i><br><b>Given that it is a simulation popping up the menu, how fast is it reasonable to expect? (Bob)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>As fast as other simulated output seems to be a desirable goal.</i><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <b>What is your normal simulated bytecodes/sec?</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>I don't know how to measure this. Is there a Smalltalk equivalent of the Linux "time" command?</i><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <b>How many bytecodes executed in that 5 minutes? </b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>or how to measure this, however, filtering mouse move should help a bit</i><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <b>how many simulated screen redraws in that interval? </b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Maybe here is an idea to stop screen redraws on loss of focus or by direct command, or by setting a rate (I like this idea) on Simulator Launch or per the command pop-up window (this would be cool)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<b> How expensive are these?</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>I don't know how to measure this</i><br><b>Three things (Eliot)</b><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1. figure out how to do it without modifying base packages, confining changes to VMMaker.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2. ask David Lewis for write permission to the VMMaker repository.<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3. commit your changed version of VMMaker, from which I can merge :-)<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <i>I will do 2 and 3 when we all agree the approach is sane<br><br><br></i><br>Finally,&nbsp; I am approaching this with two pre-conceptions  that may be wrong. (My Smalltalk work has been primarily Seaside, so my  non-Seaside repertoire is limited)<br><br>1. Morphic events only traverse the Morphic tree and are not "broadcast" for "listeners" to pick up. This will necessitate subclassing the ImageMorph the Simulator uses.<br>2. Semaphores are a 1-to-1 pipe and not a 1-to-many pipe--hence I cannot just tap into an existing Semaphore (Henrik's statement contradicts me here. I will investigate). <br><br><br>Thanks again for your time.<br><br>Cordially,<br><br><br>tty<br></div></body></html>