On 27.05.2016, at 20:36, Chris Muller <asqueaker at gmail.com> wrote:

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

Unless you want a filter that turns a mouse click into a keypress, like for automation?

Best
	-Tobias

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