Context:
At the moment, PluggableTextMorph runs the text styler immediately (#updateStyleNow) or in the background (#updateStyle) depending on the trigger:
* Immediately: The user accepts a text; we change the text programmatically (e.g., when opening a browser or selecting a different method). However, the text must be shorter than 4096 characters for this.
* In the background: All other triggers: the user types or cancels; we change the style programmatically (e.g., after a preference change); accepting or changing a text longer than 4095 characters.*
So, this strategy tries to balance maintaining a responsive UI for longer texts (especially during typing) and minimizing flickering.
Problem:
There are situations where we still have too much flickering. You may have a chance to observe this when you cancel (cmd+l) in a method in a browser. (It is best observable when keeping cmd+l pressed for a while.) Much more critical than for code editing, however, this effect is in other applications that employ frequent text updates and use a faster styler than Shout.
Proposal:
Give either the styler control over when to run in the background. Move the hard-coded 4096 to this check from PluggableTextMorphPlus>>#setText:. Introduce a second test hook with a smaller threshold for running all style requests (#updateStyle) immediately.
E.g.:
PluggableTextMorphPlus>>setText: aText
self okToStyle ifFalse:[^super setText: aText].
super setText: (styler format: aText asText).
(styler willItBeVeryExpensiveToStyle: aText)
ifFalse: [self updateStyleNow]
ifTrue: [self updateStyle]
PluggableTextMorphPlus>>updateStyle
| text |
self okToStyle ifFalse: [^ self].
text := textMorph contents.
(styler willItBeExpensiveToStyle: text)
ifFalse: [self updateStyleNow]
ifTrue: [styler styleInBackgroundProcess: textMorph contents].
Open to better names, of course. We can add a #respondsTo: check before sending these messages to the styler to keep the required styler interface minimal and fall back to "expensive, but not very expensive".
In Shout, we could implement these selector like this:
SHTextStylerST80>>willItBeExpensiveToStyle: aText
^ aText size >= 4096
SHTextStylerST80>>willItBeVeryExpensiveToStyle: aText
^ aText size >= 16384
Optionally, either PluggableTextMorphPlus or the styler could also check Smalltalk isLowerPerformance.
Workaround:
Until now, I will manually invoke the styler from the getText selector in my application in addition to registering it to the text morph to avoid any flickering.
Looking forward to your opinions!
Best,
Christoph
*NB: If we edit huge text, there can still be a larger delay but this comes from text layouting not from styling.
---
Sent from Squeak Inbox Talk