Re: [Vm-dev] One can pass events from EventSensor to the StackInterpreterSimulator

[gettimothy]

Thank you all for your input. Very useful and appreciated.

Below are your recommendations/comments (in bold)  as I have summarized them.
My notes to myself on your recommendations/comments are italicized.

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.


Check out Pharo InputEventFetcher (Henrik)
            There's already such a Semaphore operating across the VM/image divide, set by primitive 93.
            You can see an example of how to do an event listener using that in a Pharo images InputEventFetcher ;)
            Awesome. Thank you so much.
     
filtering out MouseOver events would cut down on the response time? (Henrik)
             do this first as it is an easy implement in EventSensor.

Event translation needed? (Henrik)
              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.

Use regular Morphic Event processing (Bert)
        ok, aren't  Morphic events constrained to flow along the Morphic component tree ? (Contrasted with the AXAnnouncements framework where one can "Announcer annouce" an event)
              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 (: )
         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?

Flush Primitive investigate at http://isqueak.org/ioForceDisplayUpdate  (John M.)
        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.
        curious what triggers that "need be"
        The x11 flavors just flush on each draw which make it slower 
        Very informative  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

It would be much more responsive if somehow the simulator could update the screen whenever the bitblt primitive affects the screen. (Eliot)
       John M. provides the roadmap for this above.

Ditch the change to EventSensor (Eliot)
       make the change self-contained by trying to confine the set-up of the plumbing to openAsMorph?
             Yes. The only "Morphic"  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).

Given that it is a simulation popping up the menu, how fast is it reasonable to expect? (Bob)
          As fast as other simulated output seems to be a desirable goal.
            What is your normal simulated bytecodes/sec?
           I don't know how to measure this. Is there a Smalltalk equivalent of the Linux "time" command?
            How many bytecodes executed in that 5 minutes? 
            or how to measure this, however, filtering mouse move should help a bit
            how many simulated screen redraws in that interval? 
           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)
            How expensive are these?
          I don't know how to measure this
Three things (Eliot)
           1. figure out how to do it without modifying base packages, confining changes to VMMaker.
           2. ask David Lewis for write permission to the VMMaker repository.
           3. commit your changed version of VMMaker, from which I can merge :-)
         I will do 2 and 3 when we all agree the approach is sane



Finally,  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)

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.
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). 


Thanks again for your time.

Cordially,


tty

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140131/59525057/attachment.htm