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
<[hidden email]> wrote:
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: [hidden email] [[hidden email]] On Behalf Of Nicolas Cellier [[hidden email]]
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