Hello,
Studying Scratch code I stumbled upon the fact that EventSensor primitives such as #primMousePt send a #wait2ms message before answering. In Squeak 2.8 #primMousePt was indeed a primitive; it still is in the InputSensor implementation. So my question is: what is the rationale for loosing 2 milliseconds everytime one asks for mouse position ? Stef |
On 01.02.2013, at 21:05, Stéphane Rollandin <[hidden email]> wrote:
> Hello, > > Studying Scratch code I stumbled upon the fact that EventSensor primitives such as #primMousePt send a #wait2ms message before answering. > > In Squeak 2.8 #primMousePt was indeed a primitive; it still is in the InputSensor implementation. > > So my question is: what is the rationale for loosing 2 milliseconds everytime one asks for mouse position ? > > > Stef In MVC you often have a busy loop. The wait ensures that Squeak is not hogging the whole system in that case. - Bert - |
So I take it that by carefully avoiding hyperpolling in busy loops, one
could access the event primitives without delay ? Stef |
In reply to this post by Bert Freudenberg
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 |
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 |
Dave
I assume you commented out self wait2ms. in EventSensor >> primKbdPeek and EventSensoer >> primKbdNext this indeed has the effect that the cursor is no positioned correctly in MVC when typing fast in an MVC workspace. What could be the possible side effect of removing the call to self wait2ms in these two methods? --Hannes On 2/3/13, David T. Lewis <[hidden email]> 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 > > > |
On Sun, Feb 03, 2013 at 07:57:11PM +0000, H. Hirzel wrote:
> Dave > > I assume you commented out > self wait2ms. > in > EventSensor >> primKbdPeek > and > EventSensoer >> primKbdNext > I just commented out the body of the wait2ms method, so effectively like removing it entirely from the system. > this indeed has the effect that the cursor is no positioned correctly > in MVC when typing fast in an MVC workspace. > > What could be the possible side effect of removing the call to > self wait2ms > > in these two methods? > I don't know. I guess I would want to go back and understand the original motivation for adding it. A lot a things have changed since 2005, and I would not want to do a quick fix without understanding it. But for now I'll leave it commented out in my own image :) > --Hannes > > > On 2/3/13, David T. Lewis <[hidden email]> 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 > > > > > > |
On Sun, 3 Feb 2013, David T. Lewis wrote:
> On Sun, Feb 03, 2013 at 07:57:11PM +0000, H. Hirzel wrote: >> Dave >> >> I assume you commented out >> self wait2ms. >> in >> EventSensor >> primKbdPeek >> and >> EventSensoer >> primKbdNext >> > > I just commented out the body of the wait2ms method, so effectively > like removing it entirely from the system. > >> this indeed has the effect that the cursor is no positioned correctly >> in MVC when typing fast in an MVC workspace. >> >> What could be the possible side effect of removing the call to >> self wait2ms >> >> in these two methods? >> > > I don't know. I guess I would want to go back and understand the original > motivation for adding it. A lot a things have changed since 2005, and I > would not want to do a quick fix without understanding it. But for now > I'll leave it commented out in my own image :) The author's explanation is here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147269.html It's also worth reading the responses. We should consider checking the EventSensor replacement in Pharo, because it probably became mature enough by now. Levente > >> --Hannes >> >> >> On 2/3/13, David T. Lewis <[hidden email]> 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 >>> >>> >>> > > |
Thank you Levente for digging out the reference to an earlier
discussion of the same problem. John M McIntosh http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147307.html noted that at that time already EventSensor has been replaced in Pharo and #wait2ms doesn't exist in Pharo. And Andreas Raab noted " The usage of Sensor in Morphic is completely abusive. Sensor isn't a Morphic entity; only the hand should be used to query such information." The class comment of InputEventSensor in Pharo 1.4 "An InputEventSensor is a replacement for the old Morphic EventSensor framework. It updates its state when events are received so that all state based users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor mouseButtons) will work exactly as before. The usage of these funtions is discouraged. " Can we take this version? Or are there more things to change? --Hannes On 2/4/13, Levente Uzonyi <[hidden email]> wrote: > On Sun, 3 Feb 2013, David T. Lewis wrote: > >> On Sun, Feb 03, 2013 at 07:57:11PM +0000, H. Hirzel wrote: >>> Dave >>> >>> I assume you commented out >>> self wait2ms. >>> in >>> EventSensor >> primKbdPeek >>> and >>> EventSensoer >> primKbdNext >>> >> >> I just commented out the body of the wait2ms method, so effectively >> like removing it entirely from the system. >> >>> this indeed has the effect that the cursor is no positioned correctly >>> in MVC when typing fast in an MVC workspace. >>> >>> What could be the possible side effect of removing the call to >>> self wait2ms >>> >>> in these two methods? >>> >> >> I don't know. I guess I would want to go back and understand the original >> motivation for adding it. A lot a things have changed since 2005, and I >> would not want to do a quick fix without understanding it. But for now >> I'll leave it commented out in my own image :) > > The author's explanation is here: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147269.html > It's also worth reading the responses. > > We should consider checking the EventSensor replacement in Pharo, because > it probably became mature enough by now. > > > Levente > >> >>> --Hannes >>> >>> >>> On 2/3/13, David T. Lewis <[hidden email]> 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 >>>> >>>> >>>> >> >> > > |
On Mon, Feb 04, 2013 at 01:29:44PM +0000, H. Hirzel wrote:
> Thank you Levente for digging out the reference to an earlier > discussion of the same problem. > > John M McIntosh > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147307.html > > noted that at that time already EventSensor has been replaced in Pharo and > #wait2ms doesn't exist in Pharo. MVC does not exist in Pharo either. As far as I call tell, wait2ms is called only when running in MVC. But it might be important for Scratch when running in Morphic (I don't know). > > And Andreas Raab noted > " The usage of Sensor in Morphic is completely abusive. > Sensor isn't a Morphic entity; only the hand should be used to query > such information." Right. This specifically refers to usage in Morphic. > > The class comment of InputEventSensor in Pharo 1.4 > > "An InputEventSensor is a replacement for the old Morphic EventSensor framework. > It updates its state when events are received so that all state based > users of Sensor (e.g., Sensor keyboard, Sensor leftShiftDown, Sensor > mouseButtons) will work exactly as before. The usage of these funtions > is discouraged. " > > Can we take this version? Or are there more things to change? I don't know the background on why InputEventSensor was written, but it sounds like it is Morphic specific. Dave > > --Hannes > > On 2/4/13, Levente Uzonyi <[hidden email]> wrote: > > On Sun, 3 Feb 2013, David T. Lewis wrote: > > > >> On Sun, Feb 03, 2013 at 07:57:11PM +0000, H. Hirzel wrote: > >>> Dave > >>> > >>> I assume you commented out > >>> self wait2ms. > >>> in > >>> EventSensor >> primKbdPeek > >>> and > >>> EventSensoer >> primKbdNext > >>> > >> > >> I just commented out the body of the wait2ms method, so effectively > >> like removing it entirely from the system. > >> > >>> this indeed has the effect that the cursor is no positioned correctly > >>> in MVC when typing fast in an MVC workspace. > >>> > >>> What could be the possible side effect of removing the call to > >>> self wait2ms > >>> > >>> in these two methods? > >>> > >> > >> I don't know. I guess I would want to go back and understand the original > >> motivation for adding it. A lot a things have changed since 2005, and I > >> would not want to do a quick fix without understanding it. But for now > >> I'll leave it commented out in my own image :) > > > > The author's explanation is here: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147269.html > > It's also worth reading the responses. > > > > We should consider checking the EventSensor replacement in Pharo, because > > it probably became mature enough by now. > > > > > > Levente > > > >> > >>> --Hannes > >>> > >>> > >>> On 2/3/13, David T. Lewis <[hidden email]> 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 > >>>> > >>>> > >>>> > >> > >> > > > > |
In reply to this post by Levente Uzonyi-2
On Mon, Feb 04, 2013 at 01:19:45PM +0100, Levente Uzonyi wrote:
> On Sun, 3 Feb 2013, David T. Lewis wrote: > > >On Sun, Feb 03, 2013 at 07:57:11PM +0000, H. Hirzel wrote: > >>Dave > >> > >>I assume you commented out > >> self wait2ms. > >>in > >> EventSensor >> primKbdPeek > >>and > >> EventSensoer >> primKbdNext > >> > > > >I just commented out the body of the wait2ms method, so effectively > >like removing it entirely from the system. > > > >>this indeed has the effect that the cursor is no positioned correctly > >>in MVC when typing fast in an MVC workspace. > >> > >>What could be the possible side effect of removing the call to > >> self wait2ms > >> > >>in these two methods? > >> > > > >I don't know. I guess I would want to go back and understand the original > >motivation for adding it. A lot a things have changed since 2005, and I > >would not want to do a quick fix without understanding it. But for now > >I'll leave it commented out in my own image :) > > The author's explanation is here: > http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/147269.html > It's also worth reading the responses. > The wait2ms delay is now removed from Squeak trunk. It is possible that the original problem will come back, but if so a different solution will be required. Meanwhile there is no point in leaving MVC (and Scratch?) broken, so wait2ms is gone. Dave |
In reply to this post by David T. Lewis
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 |
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 > > > > > > > > |
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 systemwindow 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 |
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 > >>> > >>> > >>> > > > > > > |
> 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 |
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 |
In reply to this post by Stéphane Rollandin
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 ... > Stef > > > -- Best regards, Igor Stasenko. |
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 >> Stef >> >> >> > > > > -- > Best regards, > Igor Stasenko. > |
In reply to this post by Bob Arning-2
On Fri, Feb 8, 2013 at 12:25 PM, Bob Arning <[hidden email]> wrote:
> This is very bad ! This makes squeak unusable for real-time animation or > music. Can it be fixed ? on Ubuntu 32bits with Pharo and Cog, I always got 2 or 3. Don't know the difference in implementations though -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill |
Free forum by Nabble | Edit this page |