[BUG] Tearing down and refreshing auto-completion popover causes lots of flickering / flashing

[nekohayo]

Describe the bug While typing, the auto-completion popover flickers a lot, which is distracting and potentially problematic for people sensitive to flashing elements.

To Reproduce Steps to reproduce the behavior:

1. Start with a blank dataset, and/or "off the record" mode (for testing purposes)
2. Type at medium speed, i.e. 30-70 words per minute instead of 100+

Expected behavior Could it be made to not completely tear down and rebuild the popover widget, and rather reuse/morph it?

And/or use a slightly longer (ex: 250-400ms) typing activation timeout delay before recalculating the choices and rebuilding the popover? A bit in the same mindset as https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1170

Maybe it could use crossfade animations too?

Screenshots or videos

https://github.com/user-attachments/assets/67ecda1e-9f5a-4274-ad81-1c8887a3f7ea

ibus-typing-booster version?

2.25.14

ibus version?

1.5.30

Distribution and version?

Fedora 40

Desktop and version?

GNOME 46.x

Xorg or Wayland?

Wayland

[mike-fabian]

@nekohayo

I am thinking about what I can do about that.

In the meantime: Did you already try the option

Use inline completion [ No | Yes, with fallback to popup | Yes, without fallback to popup ] ?

The default for this option is "No".

If this option is set to "Yes, with fallback to popup" or "Yes, without fallback to popup", then the first candidate is shown inline instead of in a popup if possible (If the first candidate happens to not be just an extension of the characters one has already written, then it is not possible). "with fallback to popup" means that if there are candidates but the first one is not an extension of what one has already typed (changes the spelling for example), then a candidate list will popup automatically. If "without fallback to popup" is used, then a candidate list does not popup if inline completion is not possible. But a candidate list can still be requested explicitly by typing Tab.

Personally I prefer "Yes, with fallback to popup".

Using inline completion reduces the flicker experience a lot because popping up a candidate list is a lot rarer.

See chapter "Use inline completion" in the documentation: https://mike-fabian.github.io/ibus-typing-booster/docs/user/#2_2_2

I find inline completion much nicer to use. But unfortunately it is very hard to use on Wayland because Wayland currently does not support preedit styling. Therefore it is currently impossible to distinguish the typed and the predicted part of the preedit when using Wayland.

You also write "There can be a log of flickering of the popover with the little hourglass" (⏳ ):

Currently I popup this hourglass immediately after a character has been typed. This is different from popping up the candidate list: The function to popup the candidate list added to be executed when idle

GLib.idle_add(self._update_candidates_and_lookup_table_and_aux)

Therefore, the hourglass sometimes flickers more agressively than the candidate list.

Because, if you type fast enough, no candidate list ist shown until the Glib idle loop is reached, i.e. not until you slow down a bit with the typing and the idle loop is reached after a typed letter. But the hourglass pops up immediately and does not wait for the idle loop to be reached.

I'll try to change that and see if it helps.

By the way, you can also switch off the hourglass completely if you want to:

The option in the last line of this screenshot of the setup tool:

☑️ Use a label to indicate busy state [ ⏳ ]

If you uncheck this option, the busy state shows no popup at all.

[mike-fabian]

@nekohayo Are you using Fedora?

I have test builds of 2.25.20 for Fedora here: https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/ You can enable that repo with dnf copr enable mfabian/ibus-typing-booster and then install the update with dnf update.

That update has a new feature to delay the calculation of a candidate list after the last key press for a certain amount of time.

By default that delay time is still 0 which should be exactly the same behaviour as before: A candidate list is calculated immediately when the idle state is reached, no matter how short the idle time.

But one can now increase that idle time by changing this setting from the command line:

$ gsettings set org.freedesktop.ibus.engine.typing-booster candidatesdelaymilliseconds 200

By experimenting I found that when I set this to something smaller than 200 milliseconds, I cannot type fast enough to prevent the display of candidates while I am typing a word. When I set it too 200 milliseconds, I can type a few letters just fast enough that no candidates are displayed until I make a short pause or slow down typing a bit.

I am not sure what the default for this should be, maybe 200 milliseconds is still a bit short, unless one types really fast one won't even notice that this delay is there. Maybe 300 milliseconds would be a good choice for the default.

I could also expose that in the setup user interface to make it easier to change.

But maybe that isn't necessary and just setting it to 300 milliseconds by default is good enough for almost everybody?

Could you please test this and tell me whether this improves it for you?

@psads-git Hi Paul, could you also test whether this introduces any regressions for you? I had to add an additional update of the preedit: when the candidate list is delayed and the delay is a bit long, it would be quite noticable when the update of the preedit is delayed until a candidate list is shown. So changed it to update the preedit immediately after each keypress. Another update of the preedit always happens when the candidate list is shown. Duplicate updates of the preedit caused some very weird problems in the past. I think it will not cause problems now because I have improved the do_reset() function in the meantime to cause no problems even when it is triggered for no good reason, so I think this change is OK. But it would be nice if you could also test this.

[psads-git]

Thanks, Mike, for your contact. I have tested the new version of ibus-typing-booster, and it appears that everything is fine regarding what was to be tested.

[mike-fabian]

@nekohayo I have new test builds for 2.25.22 now at https://copr.fedorainfracloud.org/coprs/mfabian/ibus-typing-booster/builds/

For these test builds I have changed the default for the delay time to 200 ms and made it configurable with the graphical setup user interface (in the “Appearance” tab):

[psads-git]

Nice improvement, Mike! Thanks!

[mike-fabian]

I released ibus-typing-booster 2.26.0 with this new feature:

https://github.com/mike-fabian/ibus-typing-booster/releases/tag/2.26.0