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