<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Georgia">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?<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/7/13 11:00 PM, David T. Lewis
wrote:<br>
</div>
<blockquote cite="mid:20130208040059.GA9709@shell.msen.com"
type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">On Sun, Feb 03, 2013 at 10:33:14AM +0100, St??phane Rollandin wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Also I found this on the web:
<a class="moz-txt-link-freetext" href="http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html">http://forum.world.st/Real-Slowdown-of-InputSensor-between-3-8-and-3-9-td62714.html</a>
</pre>
</blockquote>
<pre wrap="">>from where it seems that the reason for the wait is related to system
</pre>
<blockquote type="cite">
<pre wrap="">window panes resizing logic...
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<br>
</body>
</html>