#414: slow StyledTextRenderer for unicode and unprintable control cha…#1439
#414: slow StyledTextRenderer for unicode and unprintable control cha…#1439tmssngr wants to merge 1 commit into
Conversation
af468e0 to
176f48a
Compare
|
My commit used the correct, approved email address, but I've created the pull request with my GitHub account. Don't know why eclipsefdn/eca complains. |
This commit should only have committers / authors with ECA signed, but you see there two different identities : syntevo@176f48a ECA wants clarity regarding the code origin, so that every contribution is legal. |
176f48a to
c37643d
Compare
|
I wonder if it has something to do with the "Interpret ASCII control characters" setting I know that setting is only about the Console, but the console is implemented on top of StyledText. |
| } | ||
|
|
||
| private static char replaceBelowSpaceCharacters(char chr) { | ||
| if (chr >= 0x20 || chr == '\t' || chr == '\r' || chr == '\n') { |
There was a problem hiding this comment.
Should we consider allowing more?
Other characters that are used in CLI applications:
\u0007: BELL, makes a "beep" sound\u0008: BS, backspace, moves back one character\u001B: ESC, used for ANSI escape sequences (changing colors, cursor movement, clear screen, etc). This one is used quite a lot.
Since the Eclipse Console is built on top of the styled text widget not allowing ESC might break quite a lot of things.
(see https://eclipse.dev/eclipse/news/4.25/platform.php#debug-ansi-support)
…able control characters This test replaces the characters 0x00-0x1F with some alternative character (by default '?') for rendering. This improves the performance significantly.
c37643d to
56b34d1
Compare
…racters
This test replaces the characters 0x00-0x1F with some alternative character (by default '?') for rendering. This improves the performance significantly.
The previous pull request (#1425) did not work.
Note, that when changing
replaceBelowSpaceCharactersto return the commented unicode characters, the snippet will fail with a "No more handles" exception. I reckon, we best should stick to a US-ASCII character from the range 0x20<=..<0x7F.