[squeak-dev] wait2ms

David T. Lewis lewis at mail.msen.com
Fri Feb 8 04:41:35 UTC 2013


On Thu, Feb 07, 2013 at 11:20:39PM -0500, Bob Arning wrote:
> Even with the wait2ms still in there, I don't really see anything I'd 
> call sluggish in MVC. Could it be a particular VM/OS issue?

Yes, the effect is much more evident on Linux than on Windows, where
a delay of "2 ms" might be perhaps 15 ms or so in actual duration:

Time millisecondsToRun: [(Delay forMilliseconds: 2) wait] ==> 16

Dave

> 
> On 2/7/13 11:00 PM, David T. Lewis wrote:
> >Well that's really interesting!
> >
> >If I look at a Squeak 3.8 image, the MVC keyboard input works fine,
> >and the image contains neither the #zapSelectionWithCompositionWith:
> >nor the #wait2ms method.
> >
> >If I look at a Squeak 3.9 image, the MVC keyboard entry is sluggish,
> >but does not have the problem of cursor jumping to the wrong place.
> >That image has #wait2ms, but not #zapSelectionWithCompositionWith:
> >
> >So I am thinking that #wait2ms causes the sluggishness, and
> >#zapSelectionWithCompositionWith: is the source of the cursor
> >positioning problem. The two of them together resulted in the
> >completely broken keyboard entry in Squeak trunk MVC.
> >
> >It seems likely that removal of wait2ms eliminates one problem
> >(sluggish keyboard entry) and masks the other problem with
> >#zapSelectionWithCompositionWith: which is still a bug of some
> >sort that needs to be fixed.
> >
> >Dave
> >
> >
> >On Thu, Feb 07, 2013 at 10:04:11PM -0500, Bob Arning wrote:
> >>There's been something troubling me about this issue - why would 2ms
> >>mess up keyboard entry? Turns out the 2ms may not be the real problem,
> >>rather it helps get to the problem in this method from ParagraphEditor:
> >>
> >>zapSelectionWithCompositionWith: aString
> >>     "Deselect, and replace the selection text by aString.
> >>      Remember the resulting selectionInterval in UndoInterval and
> >>otherInterval.
> >>      Do not set up for undo."
> >>     | stream newString aText beforeChar |
> >>     wasComposition := false.
> >>     ((aString isEmpty or: [(beforeChar := self charBefore) isNil]) or: [
> >>         aString size = 1 and: [(Unicode isComposition: aString first)
> >>not]]) ifTrue: [
> >>             ^ self zapSelectionWith: (Text string: aString emphasis:
> >>emphasisHere)].
> >>     stream := UnicodeCompositionStream on: (String new: 16).
> >>     stream nextPut: beforeChar.
> >>     stream nextPutAll: aString.
> >>     newString := stream contents.
> >>     aText := Text string: newString emphasis: emphasisHere.
> >>     self markBlock < self pointBlock
> >>         ifTrue: [self setMark: self markBlock stringIndex - 1]
> >>         ifFalse: [self setPoint: self pointBlock stringIndex - 1].
> >>     wasComposition := true.
> >>     self zapSelectionWith: aText.
> >>
> >>if aString is more than 1 character long ( several 2ms delays might slow
> >>processing of characters to allow your fingers to get more into the
> >>typeAhead buffer), then this bit about
> >>UnicodeCompositionStream takes over and that's when I see screwed up
> >>keyboard entry.
> >>
> >>The test I used was simply repeatedly drumming my fingers over the 123
> >>keys in a workspace until the cursor jumps back a few chars and inserts
> >>somwhere other than the end of the workspace. Commenting out the wait2ms
> >>seems to correct this, but so, apparently, does reducing the method to
> >>
> >>zapSelectionWithCompositionWith: aString
> >>     "Deselect, and replace the selection text by aString.
> >>      Remember the resulting selectionInterval in UndoInterval and
> >>otherInterval.
> >>      Do not set up for undo."
> >>
> >>     ^ self zapSelectionWith: (Text string: aString emphasis: 
> >>     emphasisHere)
> >>
> >>So, regardless of whether the 2ms is good or not, it looks like there's
> >>a bug in this unicode addendum.
> >>
> >>Cheers,
> >>Bob
> >>
> >>
> >>On 2/3/13 2:00 PM, David T. Lewis wrote:
> >>>On Sun, Feb 03, 2013 at 10:33:14AM +0100, St??phane Rollandin wrote:
> >>>>Also I found this on the web:
> >>>>http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html
> >>>>
> >>>>from where it seems that the reason for the wait is related to system
> >>>>window panes resizing logic...
> >>>Stef,
> >>>
> >>>Wow, you just found the cause of our badly broken keyboard entry in MVC 
> >>>:)
> >>>
> >>>Since about Squeak 3.9, keyboard entry (especially on Linux) has had an
> >>>odd latency delay that makes it all but unusable. I just tried commenting
> >>>out the wait2ms, and suddenly keyboard entry is working again. I see no
> >>>immediately obvious ill effects (cpu use does not go too high, and things
> >>>generally still work fine).
> >>>
> >>>It seems that the delay was added back in about 2005, and very likely
> >>>the changes to input events in the Squeak 3.9 time frame caused it to
> >>>become a problem. I'm not sure the right way to fix this, but at least
> >>>now we know the source of the problem.
> >>>
> >>>Thanks!
> >>>
> >>>Dave
> >>>
> >>>
> >>>
> >
> >
> 

> 



More information about the Squeak-dev mailing list