wait2ms

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

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

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

This is very bad ! This makes squeak unusable for real-time animation or music. Can it be fixed ?

Stef