Immense amount of screen flickering

[chaosvolt]

Noticed this on switching from Windows Tiles Build 3861 to 3864. 3870 also confirmed for FUBAR.

• Black screen when loading a game, when normally it would stay at title screen for me. Sometimes it displays the "please wait while world data loads" screen instead that I used to never see, but not always. Also now yields flickering right before the save finishes loading.
• Opening crafting menu does a transition that displays the crafting tabs first, then the rest of the menu. Other menus (character screen, item action menu, construction menu) seem to flicker less.
• Repeated black flickering when transitioning to and from vehicle menu, including while installing, removing, or repairing parts.
• More flicker on transitioning from inventory to item screen.
• Map screen flickers when transitioning into and out of it.
• Flickering when scrolling down options menu.

Screenshots would be useful if my sense of split-second timing wasn't fucking awful.

[DanmakuDan]

wrefresh and other code were just updated in #13853 to handle window events in SDL better, I'm guessing if the window renders in between menus, you could get an empty screen if the screen buffer is empty. Before, the only reason the game "would stay at title screen" is because the game was too busy loading to handle screen refreshes.

[chaosvolt]

Right. It's weird that I actually got used to the game being slow. >.>

[chaosvolt]

...what.

[DanmakuDan]

The screen render is refreshing before the whole thing is ready. It's probably kind of similar to screen tearing in 3D games.

[chaosvolt]

Ah right. Definitely a surprise compared to how it used to handle rendering, far as I can tell. o.O

[DanmakuDan]

I'm guessing, based on #13949, wrefresh is being used too often in some menus, causing this kind of flickering to happen.

[chaosvolt]

Ah, thank you then.

[Barhandar]

Seeing that as well. I cannot play with it like this.

[chaosvolt]

The worst thing is it's like with map lag, I'm already starting to get used to it. >w>

[chaosvolt]

Grabbing latest build to see if this has been resolved.

[chaosvolt]

Sweet zombie Jesus, I think #13949 somehow made it WORSE.

Still getting vehicle screen flickering and all other issues mentioned before, and now scrolling down options in the options menu also appears to cause flicker, assuming I didn't notice that originally. Also now getting a flicker when transitioning from the black screen of save-loading to the game proper.

For added Fun, the map lag has returned WITH said flicker, when before the flickering displaced it.

[DanmakuDan]

The merged item doesn't cover everything, it was a scrollbar update refreshing too often. The rest of the code needs to reduce the wrefresh usage to only when the whole window is ready to be shown. The code currently uses wrefresh to draw pieces of windows as it finishes determining what each fragment is going to display.

Or maybe wrefresh needs an indicator to say the window isn't ready yet.

[chaosvolt]

Ah, I see. ._.

Though the fact I've found even more instances of flicker than was present before that PR bodes unwell. I might've just failed to pay attention, but I DEFINITELY would've noticed if the options menu in 3864 was doing what it is in 3870.

[Barhandar]

but I DEFINITELY would've noticed if the options menu in 3864 was doing what it is in

Not sure if it became any worse (as I'm just using 3861 until it's resolved), but it very definitely flickered in 3864 - both me and my friend noted that.

Given the rendering-relatedness, can #10233 be looked at/resolved, too?

[chaosvolt]

Hmm, odd in either case.

[DanmakuDan]

I'm not sure if it's better to reduce wrefresh calls to one 'whole-window' update, or add a parameter to wrefresh that allows SDL to try a screen refresh. Any suggestions?

[chaosvolt]

If I knew enough about the causes to make a guess on the best option, I would. I'm guessing, however, that neither solution will be ideal?

Hmm. This gets me thinking, anyone able to confirm if this has been a universal Windows issue, or is it only for some users?

[DanmakuDan]

I think the flickering is more obvious on slower computers using a SDL version of the game. When wrefresh is called multiple times, some calls will fall very close to the frame update timer interval and cause more than one update to be visible on screen. This probably doesn't affect curses builds, since the wrefresh call itself probably does the work of pasting the update to a console screen. It would be better to separate the wrefresh from the sdl update trigger, and call the sdl update when the window is ready to be shown.

[chaosvolt]

That could be it. Have tested it on my home PC which is even older than the laptop, and it had the same issue.

Glad to see my potato of a computer has finally reached the point where even Cataclysm gives it problems. >_>

[Midaychi]

Checking in from GalliumOS. I've been through fiddling with my drivers and settings because I noticed that after I started using the os, Cataclysm has been running incredibly slow. It was weird because everything else ran fast and fine. A few days before I tried Gallium Os, I ran cataclysm dda and it was completely fine. This was before the scaling changes. Post scaling = slow as balls.
I'm actually getting better performance in other non-cataclysm dda apps that use the gpu than I was in prior OS.

Using TILES, SOUND, LUA, RELEASE

Doesn't seem to matter if tiles are on or off ingame; Menus flicker like crazy and there's a lot of waiting in between stuff that used to be near instant, and moving around is slow even if nothings in the reality bubble and zlevels are off.

I took so long to say something because I wanted to make sure it wasn't because of the Os change. It wasn't.

[chaosvolt]

Yay. More hints that it's not merely my PC being crap? ;w;

[chaosvolt]

Well, good news is that #14221 fixed this. However, now there's a noticeable amount of menu lag. Before, the menu would flicker but not have this kind of delay.

And in addition, now just WALKING is causing unexpected delays. My potato of a PC hasn't gotten any crappier since I opened this issue, so I'm questioning how things wound up being one step forward, two steps back. ._.

[DanmakuDan]

You might want to compare performance to a version before the SDL fix. Also, the new minimap is fairly(?) resource(?) intensive (probably dependent on GPU capabilities in SDL hardware mode).

[chaosvolt]

Hmm. Need to try and recall how far back that SDL fix goes, and thus what the latest build predating it was.

Since I made my initial test on default settings and tend to turn the minimap off anyway, that might explain part of it.

That said, even when on the main menu, I noticed the oddity occur when scrolling through the key configs.

In any case, regardless of whether I figure this out entirely, it'd be a separate issue from this, so I'll go ahead and close this.

[chaosvolt]

Disabling minimap appears to eliminate walking lag, and SOMETHING I did in the process of changing settings seems to have calmed the menu-scrolling issues.

Sorry about that. ^^"