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

marcel.taeumel Marcel.Taeumel at hpi.de
Fri May 27 13:40:01 UTC 2016


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