Showing Android IME without visual glitches?

[tinne26]

I made a very simple app for android that draws a few lines in different colors on the screen and shows/hides the IME when clicking on the screen: https://github.com/tinne26/imeglitch

When the IME is requested to show (from the UI thread) on Java, the layout in Ebitengine changes for a moment (due to the insets, understandable), but there's some unusual visual flicker / glitching.

Here's a video for context, and a separate image later to appreciate that the visual glitch is not just poorly handled layout or anything on the basic game code (video taken on Android 14).

20260504_105540_2.mp4

Here's a still of the exact moment where the glitch happens, where we can see that it's not a lack of clearing, stretching or anything else, but rather a pattern appearing repeated. This actually happens during multiple frames, though it's still very quick.

Since this looks like some internal rendering issue, but before opening an issue, I wonder... has anyone managed to show/hide IMEs on Android without visual glitches?

[hajimehoshi]

Unfortunately I don't have good insights this issue.

the layout in Ebitengine changes for a moment (due to the insets, understandable), but there's some unusual visual flicker / glitching.

Isn't the keyboard overlay? Why is the widget size changed?

[tinne26]

The canvas is 1200x1920 until the IME appears, then it becomes 1200x1848. I added a DebugPrint to show it here, though you have to squint really hard on this video, lol. I assumed it has to do with android insets, but I don't know why it's only 72 pixels, such a small area. Reminds me of issues related to safe areas like #3337. I haven't checked that part of the code or if there's even anything Ebitengine can do about it.

In any case, what I wanted to say was that a canvas changing size is not an issue per se, but artifacts caused by something outside our control are more annoying.

bounds_cmp.mp4

[UnknownHawkins]

The flicker is caused by the activity being resized when the IME changes the window insets.
When the view is resized Ebiten recreates the native surface, which shows the old frame for a couple of V‑syncs and produces the “repeated‑pattern” artifact you see.

The simplest way to avoid that is to tell Android not to resize the window when the keyboard appears. Add (or change) the windowSoftInputMode flag in your AndroidManifest.xml:

<activity
 android:name=".MainActivity"
 android:label="@string/app_name"
 android:exported="true"
 android:windowSoftInputMode="stateHidden|adjustPan">
 <!-- … -->
</activity>

adjustPan keeps the window size constant and just pans the content, so Ebiten’s surface isn’t recreated and the visual glitch disappears. If you need the game UI to stay fully visible, you can also handle the insets yourself in Java and call setDecorFitsSystemWindows(false), but the adjustPan flag is usually enough for a clean IME show/hide on Android.

[tinne26]

Neither adjustPan nor adjustNothing work for me. These are treated as legacy suggestions in typical Android fashion, and can easily be ignored by the system, overridden by other options and so on.

Using WindowCompat.setDecorFitsSystemWindows(getWindow(), false), though, did work, and canvas size does no longer change when the IME shows up, which does prevent the visual glitches from ever being able to happen.

Why do we have graphical glitches on resize, though, still remains a mystery. It might be worth exploring ViewCompat.setOnApplyWindowInsetsListener to see if that can be used to notify Ebitengine earlier of potential layout changes and prevent resize glitches internally. ViewCompat.setOnApplyWindowInsetsListener is also tangentially relevant, but that might report insets even when resizing is blocked.