[Pharo-project] something we lost with events [was Optimizing RunArray]
I've got the feeling that we've lost one feature: When you're typing super fast, characters would be inserted several at once in a st80 ParagraphEditor That typically happens when the displaying or more probably the paragraph re-composition is slow. The composition/display cycle would occur after first key - giving the impression of a non responsive UI - but then consecutive key strokes would flow all in once thanks to the while loops in #readKeyboard and the buffered Queue of events. Not the most interactive UI ever, but now things are worse with current event implementation. There is a one by one keystroke / composition / display, and the result is a less responsive UI than polling ! If you edit a Smalltalk method, no problem, but try editing your 45 MByte change log just to see how deadly it feels, super fast means 0.2 Hz on my machine. I wonder how we could restore this feature... Nicolas
On 3 August 2011 03:00, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
I've got the feeling that we've lost one feature:
When you're typing super fast, characters would be inserted several at once in a st80 ParagraphEditor That typically happens when the displaying or more probably the paragraph re-composition is slow. The composition/display cycle would occur after first key - giving the impression of a non responsive UI - but then consecutive key strokes would flow all in once thanks to the while loops in #readKeyboard and the buffered Queue of events.
Not the most interactive UI ever, but now things are worse with current event implementation. There is a one by one keystroke / composition / display, and the result is a less responsive UI than polling ! If you edit a Smalltalk method, no problem, but try editing your 45 MByte change log just to see how deadly it feels, super fast means 0.2 Hz on my machine.
I wonder how we could restore this feature...
My take is that we should optimize Text data structure for editing. Because right now, its contents are stored in a single blobby string. And every time you modifying it, you have to create new string.. which consuming a lot of energy when you editing 45Mbytes :)
Nicolas
-- Best regards, Igor Stasenko AKA sig.
Does this start in any particular version? Agreed about "big" files. I have never attempted anything as large as a typical change log, but performance degrades at much more modest sizes. Events in themselves should not be a problem. Dolphin has used them from its beginnings. I vaguely recall one of its early releases having a problem with keyboard response; the then newly-formed Object Arts promptly fixed it. Otherwise, it has always been very responsive. Two things come to mind: (1) I think Smalltalk is wonderful, but I often look for ways to move tight loops into C, perhaps editors need additional primitive support; (2) the Morphic "feature" of passing colors, fonts, etc. with every drawing message might be nagging us here. At least in Windows, creating and selecting pens, brushes, etc. can take time, and I can't help wondering whether that goes on for every drawing message. Dolphin exposes the context, so one can set tools and then draw any number of times using them. Dolphin uses Windows' editing controls, so the comparison is not really valid. I do not believe that native is always better, but this might be a situation where platform widgets would have an advantage. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Tuesday, August 02, 2011 9:00 PM To: The general-purpose Squeak developers list; Pharo Development Subject: [Pharo-project] something we lost with events [was Optimizing RunArray] I've got the feeling that we've lost one feature: When you're typing super fast, characters would be inserted several at once in a st80 ParagraphEditor That typically happens when the displaying or more probably the paragraph re-composition is slow. The composition/display cycle would occur after first key - giving the impression of a non responsive UI - but then consecutive key strokes would flow all in once thanks to the while loops in #readKeyboard and the buffered Queue of events. Not the most interactive UI ever, but now things are worse with current event implementation. There is a one by one keystroke / composition / display, and the result is a less responsive UI than polling ! If you edit a Smalltalk method, no problem, but try editing your 45 MByte change log just to see how deadly it feels, super fast means 0.2 Hz on my machine. I wonder how we could restore this feature... Nicolas
participants (3)
-
Igor Stasenko -
Nicolas Cellier -
Schwab,Wilhelm K