Hi Marcel, hi all,

@Tim: I think you are not having all the use cases of text styling in mind. :-) Shout (our styler for Smalltalk code) is just one application. Users can define other stylers for other types of text that come with different performance profiles. Tool developers can configure these through PluggableTextSpec>>#stylerClass:. With regard to "on or off", it really depends. On my machine (unless I am running tens of processes in the background), styling *almost* always happens immediately (even though I can still see a small flickering in some cases if I want to). However, occasionally I still encounter a method that brings any styler to their knees (e.g., try this: Project uiManager edit: World imageForm storeString label: 'long text' shouldStyle: true).

@Marcel:

A noticeable flickering means that it will slow down the user experience when updated synchronously, right? Or is this just because of scheduling overhead?

By flickering, I mean that even some text changes its position, such as the method signature in a browser. I have still 47 FPS when keeping pressed Cmd+L. It looks as if the unstyled and the styled text are being rendered alternatingly.

If your tool wants to avoid or configure background styling, make it configurable through the tool-builder interface. Store the limit either in the styler or in the view. Then, you would not affect all existing tools.

I wanted to "affect" or fix our existing code browsing tools indeed as described above ... what issues what this are you having in mind? Of course, any added protocols on morph or styler should be optional.

While I see your concerns with #willItBeExpensive, how would you address this issue instead? :-)

Best, Christoph

--- Sent from Squeak Inbox Talk

On 2023-08-21T13:16:31+02:00, marcel.taeumel@hpi.de wrote:

Hi all --

A noticeable flickering means that it will slow down the user experience when updated synchronously, right? Or is this just because of scheduling overhead?

If your tool wants to avoid or configure background styling, make it configurable through the tool-builder interface. Store the limit either in the styler or in the view. Then, you would not affect all existing tools.

I find #willItBeExpensive a unfortunate name: (1) the "llI" combo is hard to read, (2) we don't know if it actually is expensive on the current platform and styler implementation strategy, (3) to distinguish between "expensive" and "very expensive" makes it worse because information is missing about what "being expensive" means here.

Best, Marcel Am 19.08.2023 14:49:55 schrieb christoph.thiede(a)student.hpi.uni-potsdam.de <christoph.thiede(a)student.hpi.uni-potsdam.de>: 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 [https://github.com/hpi-swa-lab/squeak-inbox-talk]

Hi Christoph --

...

A noticeable flickering means that it will slow down the user experience when updated synchronously, right? Or is this just because of scheduling overhead?

By flickering, I mean that even some text changes its position, such as the method signature in a browser. I have still 47 FPS when keeping pressed Cmd+L. It looks as if the unstyled and the styled text are being rendered alternatingly.

Let me rephrase: A scenario with noticeable flickering indicates that it will slow down the user experience when updated synchronously, right? Or is this just because of scheduling overhead?

Best, Marcel Am 26.08.2023 23:11:13 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi Marcel, hi all,

@Tim: I think you are not having all the use cases of text styling in mind. :-) Shout (our styler for Smalltalk code) is just one application. Users can define other stylers for other types of text that come with different performance profiles. Tool developers can configure these through PluggableTextSpec>>#stylerClass:. With regard to "on or off", it really depends. On my machine (unless I am running tens of processes in the background), styling *almost* always happens immediately (even though I can still see a small flickering in some cases if I want to). However, occasionally I still encounter a method that brings any styler to their knees (e.g., try this: Project uiManager edit: World imageForm storeString label: 'long text' shouldStyle: true).

@Marcel:

A noticeable flickering means that it will slow down the user experience when updated synchronously, right? Or is this just because of scheduling overhead?

By flickering, I mean that even some text changes its position, such as the method signature in a browser. I have still 47 FPS when keeping pressed Cmd+L. It looks as if the unstyled and the styled text are being rendered alternatingly.

If your tool wants to avoid or configure background styling, make it configurable through the tool-builder interface. Store the limit either in the styler or in the view. Then, you would not affect all existing tools.

I wanted to "affect" or fix our existing code browsing tools indeed as described above ... what issues what this are you having in mind? Of course, any added protocols on morph or styler should be optional.

While I see your concerns with #willItBeExpensive, how would you address this issue instead? :-)

Best, Christoph

--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]

On 2023-08-21T13:16:31+02:00, marcel.taeumel@hpi.de wrote:

Hi all --

A noticeable flickering means that it will slow down the user experience when updated synchronously, right? Or is this just because of scheduling overhead?

If your tool wants to avoid or configure background styling, make it configurable through the tool-builder interface. Store the limit either in the styler or in the view. Then, you would not affect all existing tools.

I find #willItBeExpensive a unfortunate name: (1) the "llI" combo is hard to read, (2) we don't know if it actually is expensive on the current platform and styler implementation strategy, (3) to distinguish between "expensive" and "very expensive" makes it worse because information is missing about what "being expensive" means here.

Best, Marcel Am 19.08.2023 14:49:55 schrieb christoph.thiede(a)student.hpi.uni-potsdam.de <christoph.thiede(a)student.hpi.uni-potsdam.de>: 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 [https://github.com/hpi-swa-lab/squeak-inbox-talk]