[squeak-dev] wait2ms

Bob Arning arning315 at comcast.net
Fri Feb 8 04:20:39 UTC 2013


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?

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130207/0e349388/attachment-0001.htm


More information about the Squeak-dev mailing list