[posila] [0.17.9] Weird tearing-like graphical glitch

[TruePikachu]

Already tried increasing the buffer count, to no effect.

EDIT: This is what my most recent configuration test effectively was:

Code: Select all

; MSDN says `flip` was introduced in Win8
; I don't know if it was backported in Win7 platform update
dxgi-presentation-model=copy
; I didn't know if this was an absolute count or excluding the screenbuffer
; This should either double-buffer or triple-buffer respectively
dxgi-swap-chain-buffer-count=2
; DXGI should default this to 3 if 0 is passed in
; Explicitly stated just in case that defaulting broke
dxgi-max-frame-latency=3

How expensive would it be to add a config.ini option for choosing if Present() comes before or after the WaitForVBlank call? If it's cheap enough, a temporary fix could be to make Present() be the very first thing done after WaitForVBlank() returns; this should theoretically cause Present() to take effect in the vblank period (though it should be made a hidden option instead of an automatic behaviour because it could incur a frame of latency through DWM).

EDIT 2: Just did a couple of traces with Aero enabled; the flip presentation model is available in the Win7 platform update under desktop composition only (maybe expected, since the traditional window rendering needs to blit), and the presentation queue appeared, but the present packets from Factorio still aren't making it into the queue -- the anti-tearing is being done entirely by DWM. I'd think something is being set up incorrectly, but I haven't been able to determine exactly what -- the documentation isn't being clear enough, and from whatever is clear I'm somewhat able to confirm Factorio is correct (based on examination with windbg).

[TruePikachu]

Slightly unrelated, but if this gets fixed properly, can we get the code-side solution in this thread? I was doing more research into the issue, and kept getting the forum in the results.

[posila]

Yes, flip presentation model is available on Win7 if DXGI is updated to version 1.2 (you have that according to the logs). I didn't realize it would have an effect only whit DWM enabled, but it makes sense, since it's purpose it to make DWM use applications frontbuffer directly, instead of making copy of it. And yes, as long as we render to window, DWM has final say when things get to presented to the screen and it always (or at least usually) renders desktop with v-sync on. <OT>This is particular problem with g-sync screens that typically need v-sync to be turned off to work properly, so Microsoft introduced DXGI_SWAP_CHAIN_FLAG_ALLOW_TEARING flag (which is available only on DXGI 1.5+, Windows 10 and application has to query whether HW supports it)</OT>

Your suggestion to use WaitForVBlank() helped me find following thread on GameDev.net: https://www.gamedev.net/forums/topic/63 ... -disabled/

The conclusion there is that doing WaitForVBlank() before Present() doesn't change anything, and doing Flush() before Present() fixes tearing when DWM is disabled. So I setup Win7 PC and did some experiments on my own and came to the similar conclusion. Calling WaitForVBlank() before Present() doesn't change anything; calling Flush() before Present() does. On AMD R7 250, the tear moved to the top of the screen, so it was not so obvious, but still was there. On GTX 750 Ti, tear was creating a wider band that ended just at the top of minimap. I tried to test on Intel too, but iGPU in that PC is too weak and couldn't keep up 60 FPS so I really don't know what happens on Intel; important thing for me was that Flush() didn't make it worse. (I also did some tests with DXGI_SWAP_EFFECT_DISCARD vs DXGI_SWAP_EFFECT_SEQUENTIAL, but there was no change in the behavior whatsoever)

So I'll add Flush() before Present() if desktop composition is disabled (and make it an option that will also allow to do explicit WaitForVBlank() for testing purposes), and that's the best I can do with this before exclusive fullscreen is added (besides doing DX9-DX11 interop and doing present through DX9, which I am totally not gonna do )

[posila]

Thanks for the report and for huge effort from your side while investigating this.

I added the changes to 0.17.15, I wouldn't call it fixed, but it is as good as it gets before adding exclusive fullscreen support.