Text moving to the side when a word is highlighted - "renderer_tweaks__linux" option must be adjusted

[pintassilgo]

This is not an issue as it can be fixed by tweaking options. I'm commenting here as a new issue because this repository doesn't have "Discussions" tab enabled for general talk.

I use Highlight Occurrences plugin to highlight other occurrences of the word under the caret. But I noticed the highlighting of the word causes the rest of the line (at the right of the highlighted word) to slightly move to the side (by 1px or 2px).

So I played with every renderer_tweaks__linux possible combinations to test if one of them is capable to fix this rendering issue. I found out the key chars of this option for this rendering issue are w and o.

• Using w without o makes the rendering very bad, the rest of the line after the highlighted word moves one space width to the left (eating the space char after the highlighted word).
• Using o without w has the opposite effect: the rest of the line moves one space width to the right (rendering an extra space char after the highlighted word) .
• Using both ow the rendering is perfect, nothing moves when a word is highlighted.
• Using neither o or w produces my initial report: the highlighting of a word cause the rest of the line to slightly move to the side (by 1 or 2px).

In the end, my final value for this option is nosw, but as I said the letters affecting this rendering issue are o and w.

I can't test on other systems, I'm just sharing my results here because maybe using both o and w should be the default on Linux as at least for me it produces the perfect rendering.

Since this is just talk, you can close this at any time.

[Alexey-T]

Inclustion of 'o' to option default is not nice, it makes rendering slower.

  if 'o' in value: Calculate 'offsets' for individual characters, ie use slower API to render.
                   On Windows, 'offsets' don't decrease rendering speed.
                   On macOS, 'offsets' decrease (2x) rendering speed.
                   On GTK2 and Qt5, 'offsets' decrease rendering speed.

but on Qt5/qt6, 'o' is used in default.

    TextoutNeedsOffsets:=
      {$if Defined(LCLWin32) or Defined(LCLQt5) or Defined(LCLQt6)}
      true
      {$else}
      false
      {$endif} ;

option 'w' is not affecting speed. it's in default only on macOS.
why?
see default.json

                   On GTK2, 'w' is not needed.
                   On Qt5, 'w' gives various results, it depends on Desktop Environment.

[pintassilgo]

Fine, thanks for the explanation. It's up to you to decide, I just shared my results.

I think that, from the user's perspective, the rendering issue is more important than some decreasing performance in edge case (at least I still couldn't perceive any decreased performance).

The rendering issue might cause new user to think it's a buggy/unfinished software when it's actually excellent.

[Alexey-T]

The decreased speed of rendering affects how fast we can scroll by arrow-keys... and CPU loading..