Smalltalk › Squeak › Squeak - Dev

wait2ms

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

David T. Lewis

Re: Delay on Linux (was: wait2ms)

On Fri, Feb 08, 2013 at 09:41:05AM +0100, St?phane Rollandin wrote:
> >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 ?
>

Yes, Cog on Linux is much better in this regard (I was using an interpreter VM):

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

Dave

Eliot Miranda-2

Re: Delay on Linux

In reply to this post by Bob Arning-2

On Fri, Feb 8, 2013 at 3:25 AM, Bob Arning <[hidden email]> wrote:

It's mostly 2 and occasionally 3 on a Mac. FWIW.

On 2/8/13 3:41 AM, Stéphane Rollandin wrote:

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 ?

Yes. I believe the issue is the linux kernel version. Upgrade to a 2.6 kernel.

e.g. using Cog on a Linux redacted 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 athlon i386 GNU/Linux:

(1 to: 20) collect: [:i| [(Delay forMilliseconds: 1) wait] timeToRun] #(3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3)

(1 to: 20) collect: [:i| [(Delay forMilliseconds: i) wait] timeToRun] #(3 3 3 6 6 9 9 9 12 12 12 15 15 15 18 18 18 21 21 21)

Stef

--
best,

Eliot

timrowledge

Re: Delay on Linux (was: wait2ms)

In reply to this post by Frank Shearar-3

On 08-02-2013, at 4:46 AM, Frank Shearar <[hidden email]> wrote:

> On 8 February 2013 12:36, Igor Stasenko <[hidden email]> wrote:
>> On 8 February 2013 10:41, Stéphane Rollandin <[hidden email]> wrote:
>>>> 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 ?
>>>
>> no without modifying VM i think ...
>
> I suspect you're right, Igor: on Cog there's much less variance
>
> (1 to: 100) collect: [:i | [(Delay forMilliseconds: 2) wait] timeToRun]
>
> "on Cog => #(2 4 2 2 4 2 2 4 2 4 4 2 4 2 2 4 2 4 4 2 2 2 2 4 2 2 2 4
> 4 2 4 2 2 4 4 2 4 2 2 4 4 2 2 2 4 4 2 4 2 2 2 4 2 2 2 4 2 2 2 4 2 2 4
> 2 2 4 4 2 2 2 4 2 2 2 4 2 4 4 2 4 4 2 4 4 2 2 4 2 2 2 2 4 2 2 2 4 2 2
> 2 4)"
> "on Interpreter => #(18 41 41 25 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
> 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
> 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 4 2 2 2 2 2 2 2 2 2 2 2 2 2
> 2 2 2 2 2 2 2)"
>
> frank

Oh deary me. Looks like you might need to use a *real* operating system.

On Pi RISC OS, plain old interpreter -
|times|
times _ OrderedCollection new:100.
100 timesRepeat:[
start _ Time millisecondClockValue.
(Delay forMilliseconds: 1) wait.
times add: Time millisecondClockValue - start].
times

-> an OrderedCollection(2 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 9 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh, as he realised Piglet was undercooked.

David T. Lewis

Re: wait2ms

In reply to this post by Bob Arning-2

I think this is fixed now in trunk (ST80-dtl.141). Indeed we were dealing
with two separate problems that conspired to make a real mess of keyboard
input in MVC. The wait2ms causes sluggish input, especially on a VM that
has poor delay time resolution. And the problem that you (Bob) identified
below caused cursor positioning to be completely wrong in the case where
the keyboard input was was two or more characters (because of the wait2ms
delay).

That second problem happened because the unicode conversion takes the
character prior to the selection pointer, which I think serves as an
indication that we are in the non-ascii world, and appends the new text
input through a UnicodeCompositionStream. Pointers are adjusted down
by one character to do this, then the resulting text is zapped back to
the paragraph. The bug was that the pointers needed to be moved forward
again by one character afterward the zapping in order to get back to
their correct position.

I am multi-lingual impaired, so if someone with a Japanese keyboard
could open a workspace in MVC and see if characters can be properly
entered, that would be good :)

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