[squeak-dev] Faster window drag for Morphic

Tim Johnson digit at sonic.net
Sat Apr 2 17:11:50 UTC 2022


I've been surprised about how SystemWindows become active when dragging 
other SystemWindows, Inspectors, PluggableXYZ windows (or morphs in 
general?) on top of (or over) them.  It produces a noticable lag in the 
UI.  This is only evident when the preference 'Fast window drag for 
Morphic' is turned OFF and whole windows are being dragged.  (Having Soft 
shadows enabled slows it down further, I think.)

IMHO these windows would not accept the drop, so they should not become 

I did some spying on the UI process and found that all code panes are 
being redrawn (?) when dragging morphs over SystemWindows.  This is easily 
and quickly defeated/remedied by commenting out 'self activate' in the 
following method, as follows:

SystemWindow>>#mouseEnterDragging: evt
 	"unlock children for drop operations"

 	self flag: #performance. "mt: There may be no need to change 
appearance if no widget wants the drop."
 	self isActive ifTrue: [self lookFocused].

 	(self isActive not and: [evt hand hasSubmorphs]) ifTrue: [
 		"self activate." "unlock contents for drop"
 		evt hand addMouseListener: self. "for drop completion on submorph"

My question:  could the drag-and-drop "#wantsXYZ" protocol be followed 
here to optimize this?  Or perhaps there is some other way to /not/ make 
the window active (and thus redraw all its panes, I think?) when a morph 
/it does not want/ is dragged over it?


More information about the Squeak-dev mailing list