clear window line by line, skipping untouched lines

[db48x]

Summary

Bugfixes "fix windows with missing header text"

Purpose of change

Describe the solution

Many of the windows in the game, especially the ones with scrollbars, create multiple overlapping windows and then draw them in an odd order. This results in overdraw, but that was partly compensated for by the cache that we removed. Now that we clear the whole window in one go, this causes artifacts as we erase text that was already drawn in a different window that overlaps the current one. By erasing only the lines that are touched, we avoid the problem.

Fixes #71994.

Describe alternatives you've considered

We could just change every window to avoid the overdraw. It is almost always because it goes back and calls draw_scrollbar to add a scrollbar to the window after it has already drawn the window border and header text. By moving the call to draw_scrollbar up so that it happens before printing the header text, the problem would also be avoided.

Testing

I just manually tried out every window I could find that has a header and a scrollbar, including those mentioned in the bug report.

[Qrox]

Many of the windows in the game, especially the ones with scrollbars, create multiple overlapping windows and then draw them in an odd order. This results in overdraw, but that was partly compensated for by the cache that we removed.

Our code has always worked in curses so I think the SDL framebuffer code was simply mimicking curses behavior.

We could just change every window to avoid the overdraw

I think this PR is the correct solution as it avoids inconsistencies between the curses and SDL builds which might make testing harder.

erasing only the lines that are touched

Was this (instead of erasing the cells that are touched) the behavior before the removal? I'm worried that undrawn parts of a line might still be overwritten.

[db48x]

Many of the windows in the game, especially the ones with scrollbars, create multiple overlapping windows and then draw them in an odd order. This results in overdraw, but that was partly compensated for by the cache that we removed.

Our code has always worked in curses so I think the SDL framebuffer code was simply mimicking curses behavior.

Very likely.

erasing only the lines that are touched

Was this (instead of erasing the cells that are touched) the behavior before the removal? I'm worried that undrawn parts of a line might still be overwritten.

Yes. Either the line was touched or it was not, and the lines are all filled with spaces when the window is created. Thus the whole line is drawn no matter what.

[katemonster33]

I compiled this locally and it seemed to fix the issue

[IdleSol]

Good news, everyone!

Game version: cdda-windows-tiles-x64-2024-02-28-2115

The first problem.

1. Default settings
2. Enable imGui (settings / options / interface / Use imGui UI: true)
3. Open the keybindings menu
4. Close the keybindings menu
5. Look at the bottom of the screen

A similar line appears on any invocation of the keybindings menu. For example:

3. Start creating a new world
4. In the difficulty selection menu, press ?
   or
5. setting /safemode
6. press a (start creating a new rule )
7. press enter (set rule name)
8. press F1 (calling the keybindings menu)

If Use imGui UI: false, there's no problem.

I'm assuming the problem is the size of the keybindings menu. It's longer than it should be.

The second problem.
The keybindings window again (settings / keybindungs). The search string does not become active.

To be more precise, it sometimes becomes inactive (does not allow you to enter text). The behavior is as follows. When opening a window, the cursor blinks once and disappears. When pressing keys nothing is typed.

1. Default settings
2. Enable imGui (settings / options / interface / Use imGui UI: true)
3. Open the keybindings menu
4. Try typing. If you succeed, go to the next step.
5. Close the game and open it again.
6. Go to step 3

Alternatively 1.

1. Open the keybindings menu
2. Close the keybindings menu
3. Open another menu (safemode, options or create a world)
4. Close this menu
5. Go to step 1

Alternatively 2.
After opening the keybindings menu, press enter. Try typing in the text

If you disable imGui, everything works fine.

P.S. Or was it necessary to create a new topic?

[IdleSol]

Hotkey menu for the hotkey menu?

1. Open the keybindings menu
2. Press ? - another keybindings menu opens

[db48x]

Separate bug reports for separate bugs please!

[IdleSol]

Separate bug reports for separate bugs please!

Done.

• ImGui Keybindings window. Leaves an image artifact #72065
• ImGui Keybindings window. Inactive search bar #72066

Hotkey menu for the hotkey menu?

Is it a bug? Or is it normal?

And these are for attention. I apologize if you've already seen them.

• imgui Keybinding screen unintuitive mouse support #72057
• Imgui When I resize window, the keybinding menu doesn't resize (doesn't move to center) #72058
• Imgui Keybinding window when scrolling, mouse click selects wrong entry #72059

[Qrox]

Hotkey menu for the hotkey menu

You're supposed to be able to change the keybindings of the keybindings menu itself, so it is expected, unless something else is wrong.

[IdleSol]

• ImGui Keybindings window. The content depends on the Use ImGui UI option #72068