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: > 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. |
(Pharo CC removed only because I can't post there; feel free to repost.)
On 3 August 2011 02:38, Igor Stasenko <[hidden email]> wrote: > On 3 August 2011 03:00, Nicolas Cellier > <[hidden email]> 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 :) We do have tools available for optimising the editing of structures: a Huet-style zipper (Zippers) and one based on partial continuations (ZipperControl), both here: http://www.squeaksource.com/Zippers.html The former has no dependencies. You can install ZipperControl thusly: Installer ss project: 'Control'; install: 'Control'. "Requires a recent Cog VM, or the old Interpreter VM. If you get 'Computation terminated' when you try to run the tests, your VM's too old." Installer ss project: 'Nutcracker'; install: 'Maybe'. Installer ss project: 'Zippers'; install: 'ZipperControl'. The Zippers package requires you to define your traversals manually by "differentiating" the structure over which you traverse. However, it's very simple to use. ZipperControl lets you traverse "right" through the structure (I've not implemented "up", "down", "left"), but you only need to define a traversal. Why, yes, I do have an ulterior motive! I'd like to see these guys used in anger! frank >> Nicolas >> > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Free forum by Nabble | Edit this page |