[squeak-dev] Re: Event filters for user input events (i.e. mouse clicks etc.)

Chris Muller asqueaker at gmail.com
Fri May 27 18:36:00 UTC 2016


Hi Marcel, global keyboard shortcuts are important, a 1-microsecond
slowdown per event does not sound significant.  But, yes, for
performance critical code like event handling, its probably worth
adding an instvar than a dictionary lookup.

I don't know under what case an event-type would ever change.  Events
are events generated by the input devices.  They should basically be
created and then immutable...

On Fri, May 27, 2016 at 8:40 AM, marcel.taeumel <Marcel.Taeumel at hpi.de> wrote:
> marcel.taeumel wrote
>> Hi, there.
>>
>> Here is a new version of event filters with support for separating
>> capturing filters from bubbling filters.
>> https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-capture
>> https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-flow-bubbling
>>
>> Here is the change set:
>> event-filters.cs <http://forum.world.st/file/n4896486/event-filters.cs>
>>
>> Note that you should either use a fresh trunk image with the latest
>> updates OR unload all the changes from my previous change set because I
>> cleaned up this one. So, there will be some "method removed" calls
>> missing.
>>
>> Anyway, with support for capturing filters, you can also filter, for
>> example, mouse events for system windows that are always active (see
>> preference "Windows Active Only On Top" disabled).
>>
>> wnd := ActiveWorld submorphs fourth.
>> mouseFilter := PluggableEventFilter on: [:evt :target | evt ignore].
>> wnd addMouseCaptureFilter: mouseFilter.
>> wnd removeMouseCaptureFilter: mouseFilter.
>>
>> See how the behavior is different when you use the filter for the bubbling
>> phase:
>>
>> wnd addMouseBubbleFilter: mouseFilter.
>> wnd removeMouseBubbleFilter: mouseFilter.
>>
>> Note that event bubbling is implemented in MorphicEventDispatcher. If
>> there would be no bubbling, those filters would be meaningless. However, I
>> am not aware of an alternative event dispatcher for Squeak's Morphic.
>>
>> What other dispatch patterns are out there? :-)
>>
>> Best,
>> Marcel
>
> Hi, there.
>
> I benched the event filters mechanism without having any active filters to
> reveal the impact of my changes. Here is the benchmark:
>
> 0) Close all windows.
>
> 1) Open a system browser and position it in the upper-left corner right
> below the world main docking bar.
>
> 2) Open a workspace, not covering the system browser.
>
> 3) Execute some code:
>
> event := MouseButtonEvent new
>                 setType: #mouseDown
>                 position: 100 at 100
>                 which: 2r000 "no change"
>                 buttons: 2r100 "red/left pressed"
>                 hand: ActiveHand
>                 stamp: 0. "not needed"
>
> [
>         event resetHandlerFields.
>         event hand sendMouseEvent: event.
> ] bench.
>
> On my Windows 10 machine (MS Surface Pro 3, Core i7 mobile) with Cog/Spur
> #3663 and Squeak #15987 I got:
>
> Before: 3.73 microseconds per run
> After: 4.5 microseconds per run
>
> This tests a mouse-down event because it involves full dispatching (resp.
> capturing) and handling (resp. bubbling) without taking the shortcut via
> mouse focus (or keyboard focus).
>
> This benchmark combined with MessageTally class >> #spyOn: provided
> interesting insights about expensive calls.
>
> About 5.9 percent are spend for sending generic and mouse bubble filters.
> Note that 4.1 percent are spend for accessing the Morph's properties to find
> out that there are no filters at the moment. This could be optimized by
> adding instance variables to MorphExtension.
>
> (Interestingly, about 11 percent (before: 12.7 percent) are spent in Morph
>>> #handleMouseDown: to call HandMorph >> #removePendingBalloonFor:.)
>
> (On a side note, the current way to provide global keyboard shortcuts eats
> up 47.1 percent (before: 48.4 precent) for this mouse down handling because
> of installing/removing event listeners in PasteUpMorph >>
> #becomeActiveDuring:. But this will be optimized on a few days.)
>
> The following questions remain:
> - Can I put this in trunk and use it to improve the implementation of global
> keyboard shortcuts?
> - Should I add instance variables in MorphExtension to speed-up the look-up?
> Note that I already did add instance variables to HandMorph to speed-up the
> look-up of global event capturing filters.
> - Is it conceptually good to re-evaluate the filters if one of them changes
> the kind of an event? This affects only mouse event filters and keyboard
> event filters that convert between mouse and keyboard. Note that an endless
> loop is possible if such filters do not converge.
>
> Best,
> Marcel
>
>
>
> --
> View this message in context: http://forum.world.st/Event-filters-for-user-input-events-i-e-mouse-clicks-etc-tp4895521p4897830.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>


More information about the Squeak-dev mailing list