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
OK - my suggestion is to make this much, much, simpler. Have a preference for whether styling is done or not. Have the preference wizard point out if the machine seems slow (it already does this, neh?) and explain that turning off auto-styling might be a good idea.
Of course, making the styler much faster would also assist in making this better.
On 2023-08-19, at 5:49 AM, christoph.thiede@student.hpi.uni-potsdam.de wrote:
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.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RBT: Rewind and Break Tape
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@student.hpi.uni-potsdam.de christoph.thiede@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 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]
Remember that not all machines are 4GHZ 12core with 40gpus and 64Tb of ram! My programming is done on Pi4 machine, at least in part to make sure the stuff I write will perform better on most machines.
If you really want to try to make the system automagically decide what to do with style or not, maybe use a timeout like the socket connections; start styling, timeout if it takes too long and use the plainest text.
On 2023-08-26, at 2:10 PM, christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de wrote:
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).
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Plan to be spontaneous tomorrow.
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]
Hi Marcel,
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?
Yes, the flickering just occurs due to scheduling overhead. If I forward every #updateStyle to #updateStyleNow, that flickering is gone away.
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2023-08-28T16:45:13+02:00, marcel.taeumel@hpi.de wrote:
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(a)student.hpi.uni-potsdam.de <christoph.thiede(a)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(a)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]
squeak-dev@lists.squeakfoundation.org