Stuttering (seems to be due to WS_POPUP removal?)

[thatsage]

Build
1.5.0-dev-2285-gc23241c (latest as of today)

Settings
OpenGL
issue doesn't happen in DX11
Safe Preset /w vsync off or on (in pcsx2)
Software or Hardware

Issue
Games stutters every 15-20 seconds or so, for a few seconds, despite running in 60fps and exhibiting no slowdowns or issues with sound etc.

Fix
After looking around I found issue #1437 and using the specific GS plugin provided there which from my understanding added a flag called 'WS_POPUP' seems to completely resolve the issue.

PC specifications:
WINDOWS 10 64bit build 1709
NVIDIA GTX 970 driver version 390.77
8GB RAM
i5-4690k

Note this issue persisted for me across truly many versions of drivers and windows 10 builds, until literally today when I stumbled upon that fix.

[vsub]

If I remember correctly,In my case the problem existed only while using OGL and exactly removing the WS_POP fixed the problem.
This was while using Win7 but there was other people reporting that it also happens on Win10

And btw,I don't know if this is related but I recently installed some windows updates(cumilative january updates)and soon after that I notest some weird stuterring on a pc game I was playing(in window mode)before the update and that game can barely make the cpu\gpu break a sweat.

Windows 10 x64
nVidia GTX 1060
16GB Ram
i7-6700HQ
And no,the laptop is not working in some power saving mode

[MrCK1]

WS_POPUP was removed primarily because it caused tearing with Nvidia cards on OGL

Quotes from #2058
mirh said:

Yes it is.
It was originally removed here because it was breaking v-sync [in our actually broken opengl implementation, in retrospect]
...
Fast forward these last months of nvidia drivers maddens, it reportedly solves stuttering on nvidia driver - without passing through the headaches of DWMflush.

gregory38 said:

The removal of the WS_POPUP flag was done to avoid some tearings on Nvidia. I'm afraid that tearing
will come back. However, users can still force vsync in the driver to avoid tearing.

[thatsage]

Yes indeed, but the issue shouldn't be left like that as it creates an even larger problem for some Nvidia users like me. And as said by gregory38 we can always force vsync through NVCP (not that I need to even with the flag). There's no other solution for the stutter it would seem other than using that flag, so I think it must be introduced back in some way. There was talk of making it a toggle option maybe, why not do that?

For example it could be called "alternate rendering window" with the description stating "use this if experiencing problems with normal fullscreen, for example stuttering. More relevant for Nvidia users. Warning: may cause issues with vsync (can still be forced through control panel)."

[mirh]

The thing is, nobody in their goddamn mind seems to have understood what's going on.
With nvidia cards at least.
I was hypothesizing lack of WS_POPUP had something "interfering" with exclusive fullscreen, yet turtleli here mentioned this was working.
...
is tired and doesn't feel like to TL;DR the reminder of the thing
In the current builds, right behavior should be enforceable with EnableVsyncWindowFlag=enabled

---

If you then are also in the mood of testing (a novelty across people affected by this problem, if I can say) then try to experiment with all the possible combinations of windows fullscreen optimizations, NVCP fullscreen optimizations and ws_popup flag.
Also please note down windows build and gpu driver version.

[thatsage]

I updated OP with build and driver version numbers. I'll be happy to do testing, much better this is fixed rather than me staying on the same plugin as it becomes outdated. But, I'm no developer so I need a bit more directions if that's okay, I'll do what I can. Disabling windows fullscreen optimizations in properties doesn't change anything for me - tried with the "default" plugin of course, which comes with the latest SVN.

General things I tried before making this issue: limiting to 60fps with riviatuner, setting frames to render ahead to 1, combination of PCSX2 and NVCP vsync, also NVCP triple buffering - none of these fixed the issue.

[mirh]

Oh, god, that's the spirit. I swear I'm so pissed about people complaining but 0 will.

First: undo whatever you might have done.
Does EnableVsyncWindowFlag=enabled (in pcsx2_ui iirc) in latest git equally fixes it?

[thatsage]

I re-downloaded latest git, set it up everything default and only set EnableVsyncWindowFlag=enabled as you said in the ini. It didn't fix the issue.

[mirh]

......
Can you please spam that in every .ini file then?
I'm going to band my head in the meantime.

[thatsage]

I added that to every other .ini and it did't fix the issue. Seems like you were sure it would've?

[mirh]

It should be supposed to add ws_popup...
Maybe try true, or 1?
I'm loosing my mind over this.

[gregory38]

I think entry should exist (disabled by default). I think, from top of my mind, value are enabled/disabled

[mirh]

In mine too, but I don't know what else to think.

[FlatOutPS2]

Does it require Preset to be disabled?

[thatsage]

Well I gotta correct myself, the stutter actually doesn't happen in DX11, it happens with OpenGL only. At any rate, setting EnableVsyncWindowFlag to enabled or back to disabled (btw 1 changes to enabled after running pcsx2 automatically) doesn't fix the issue, again DX11 never had it, sorry about that...

[mirh]

Yes, we know it's opengl only.
Now, can you please try to see if unticking the "preset" checkbox in the pcsx2 settings gui changes anything?

[thatsage]

I tried that too, before opening this issue but also after changing the .ini files. I also tried with pcsx2 vsync enabled in addition to just unticking the preset checkbox. Again, nothing made a difference.

[mirh]

Can you try setting zoom to 100%?
Did you use fresh settings files?

[thatsage]

Zoom is on 100% and I never changed that, it's the default value.

Yes, I downloaded a new .rar and extracted it to a new separate folder. Only thing I copied was a save-state for Shadow Hearts. Just to be sure, I tried now without loading the save-state, still stutters.

[mirh]

Then the question is WTF there was of different in the dll yo....
WAIT A MOMENT
Did you get the DWMFlush gsdx by chance?

[thatsage]

Terribly sorry I didn't just link the damn thing I was using as a fix in the first place...

#1437 (comment)

It was actually your comment in the forum which took me to it lol.

[mirh]

... So.. I guess like..
That's what I had shunned with "I guess we could close this issue - if somebody still have stuttering, we can open another one - focused perhaps just on DWM issues"...
...
So.. I'm tired of groping through the darkness, and I have an half idea.
Could you please first test if stuttering is reproducible here with opengl? (and if it gets fixed by replacing the dll)

[turtleli]

So have you tried fullscreen with EnableVsyncWindowFlag=enabled in PCSX2_ui.ini (GSWindow section) and with Aspect Ratio set to "Fit To Window/Screen"?

[thatsage]

Could you please first test if stuttering is reproducible here with opengl? (and if it gets fixed by replacing the dll)

Using the plugin you provided and the .ini too, stutter happens. Switching to the dll I linked earlier fixes the stutter (but since the .ini is just defualt settigns and I'm using a diffrent gdsx.dll, that's not surprising right?)

So have you tried fullscreen with EnableVsyncWindowFlag=enabled in PCSX2_ui.ini (GSWindow section) and with Aspect Ratio set to "Fit To Window/Screen"?

No, actually, I tried with Aspect Ratio set to 4:3 standard until now. I changed to Fit to Window/Screen, and what do you know, first there was tearing - never before... Then I turned on PCSX2 vsync, no tearing anymore... And it seems no stutter anymore at all as well.

But soon as I switch to 4:3 standard, window or FS, I get the stutters creeping in every now and then.

[mirh]

So that explains why people might have been reporting conflicting reports.

And.. are you saying that "fit to window/screen" gets you tearing EVEN in windowed mode?
And that just enabling pcsx2 vsync (plus the aforementioned) fixes both this and stuttering, even without ws_popup?

EDIT: ohhhhh, try to force disable g-sync

[thatsage]

And.. are you saying that "fit to window/screen" gets you tearing EVEN in windowed mode?

No no, in window mode no tearing no matter what.

just enabling pcsx2 vsync (plus the aforementioned) even without ws_popup?

Actually no, I meant to test without ws_popup too to see if it was needed, and thought it wasn't, but apparently the .ini didn't save changes and it was actually still enabled. After actually disabling it, the method no longer worked.

To summarize: to fix stutter for me, I first must edit .ini and set EnableVsyncWindowFlag=enabled and also must set Aspect Ratio in GS window to "fit to window/screen" OR to "16:9", meaning the actual issue is when it's set to 4:3 standard (but also, those two other options still need the .ini edit). Together, aspect ratio change and .ini change, these changes introduce good old screen tearing. Both pcsx2 Vsync and NVCP vsync can fix that tearing without causing any new stutter, I see no difference between either method. But if aspect ratio is back on 4:3, there's no tearing anymore (even without vsync), unlike 16:9 or fit to window/screen, and it stutters again.

EDIT: ohhhhh, try to force disable g-sync

I did :) at first I actually tested on my TV which is how I play emulators, but that got bothersome so I set my monitor to 60hz and disabled gsync, which pretty much matches the TV other than native resolution.

With g-sync enabled, I actually didn't get the "prolonged" stutter every now and then, but frame-pacing was all sorts of wrong lol so yeah I turn it off for emulators, or just use the TV.

[mirh]

Ok so.. WS_POPUP, plus FitToScreen, plus 100%zoom, plus v-sync fix it all.
(which is kinda what we already know, except WTF even in windowed mode?)
Just to be sure then:

• is v-sync needed just to solve tearing, or even stuttering (e.g. in windowed mode)
• with 4:3 there's no way whatsoever to get rid of stuttering (aside of the "DWMflush" dll)?

[thatsage]

with 4:3 there's no way whatsoever to get rid of stuttering (aside of the "DWMflush" dll)?

Yes.

is v-sync needed just to solve tearing, or even stuttering (e.g. in windowed mode)

Vsync is only needed to solve tearing which only happens in fullscreen mode. Vsync isn't needed to actually stop the stuttering, but it stops the tearing that WS_POPUP + FitToScreen/16:9 cause in fullscreen.

In window mode, there's no tearing, and it actually does stutter like normal, all the changes don't make a difference there. It was late yesterday, my mind was a bit jumbled yesterday sorry heh. Yes, it does stutter still in window mode.

[mirh]

Ok then
(whatever fit to screen in windowed mode might be tampering with, I guess like that also explains why "zoom" was reported to be re-introducing stuttering)
So, nonetheless since I so much hate magic, without further ado:

---

Mighty @Kaldaien I summon you.
We have been hitting mysteries of the nvidia driver for the better part of the last two years.
When using OpenGL renderer (unless you happen to meet the conditions for exclusive fullscreen mode*) you get loads of stuttering.
We found out calling DWMFlush before presenting every frame fixes even the remainder of cases, but if possible we'd like to avoid that (it framelocks you)
G-sync going wild might have explained windowed mode weirdness, but disabling it reportedly leads to nothing - and I don't know where else to bang the head.
I guess like you don't have ps2 bios/games available, but you can readily check out this test case.
Sources are here.

*which are WS_POPUP window style and surfaces size == window size (I once though these had to be in turn equal to screen size, but it doesn't seemingly matter whether you are in fullscreen mode or just windowed, for this problem to manifest)

[gregory38]

We should really update PCSX2 to always use a surface of the window size. But we must send the rendering size to the GS plugins. It will at least remove one parameter of the equation.

[mirh]

I wouldn't know how nicely that'd play with integer scaling.

[BParks21]

I'm using the flag option enabled. Now with fit to screen instead. With the flag option enabled there is no stutter in fullscreen or window mode. With flag enabled plus limiting to 60 with riva i get the same visible smoothness but frame times are locked perfectly at 16.6ms. With no flag enabled i get awful stutter in window and fullscreen. With flag disabled and the FPS limited to 60 i get stutter in both window and fullscreen even when the graph shows fairly stable frame times. The first image is just flag enabled. The second is flag enabled plus 60fps limit. the 3rd is no flag and 60 limited.

[mirh]

With the flag option enabled there is no stutter in fullscreen or window mode.

Thanks. god.
And I hope you can also confirm that there is no tearing in either dx and opengl renderer, in both windowed and fullscren modes (at least when vsync is set in pcsx2).

So, again.. The only hard blocker to get the flag back, is having popup windows cooperate when exclusive fullscreen triggers.
If you could also signal this in the other 999 emulators threads involved...

[BParks21]

Yes with the flag option enabled there is no tearing or stutters both in DX and opengl windowed or fullscreen. I did notice DX has even better frame times in the graph than opengl though. A perfectly flat line with 16.7ms frametimes. Yes i will.

[Margen67]

Windows 8.1+ have forced triple buffering/compositing with non-exclusive fullscreen so this would be nice to have.

[Nicholas-Steel]

I was getting periodic long bursts of Frame Doubling with my Nvidia Geforce 1070Ti and OpenGL, I'll give this EnableVsyncWindowFlag a shot to see if it improves the situation.

[Nicholas-Steel]

Nah it didn't resolve it. I'm not entirely sure what is going on but the emulator works fine and then something, unsure what, causes it to fall in to a bad mode where frame duplication frequently happens. The only way to stop it occurring, at least temporarily, is to do something that makes the screen flicker like opening and closing the graphics plug-in UI.

Unsure if I should make a new report to discuss this or discuss it on the forum.

[ichee]

Setting display refresh rate to 59.94hz seems to resolve stuttering. For displays that can only do 60hz at the nearest, setting emulation speed to 100.1% should fix the problem, though currently emulation speed can’t be set to a float value.
Should be able to verify by temporarily setting the frame limit to 60 in the pcsx2_vm.ini.

Otherwise, some form of resampling would be needed.

Just so you should know, some native PC games behave similarly with nvidia cards with regard to occasional stuttering, primarily the console ports.

Windows 10
Intel 9820x
Nvidia gtx 1080ti

[Nicholas-Steel]

I made a report that explains the issue, and includes a video recording ichee: #3571

[clang88]

I can confirm the stuttering issue on both PCSX v1.6 and the latest pcsx2-v1.7.0-dev-944-g7c072094a-windows-x86.

I can however not confirm that the issue is only visible with OpenGL. While different, I am observing some stutter with the D3D Renderer aswell. This also exhibits in somewhat erratic jumps of reported FPS/Game Speed in the PCSX Window (Game Speed jumps between 99% and 101% while FPS varies from 59.9x to 60.7x. The issue is actually also present when using the Software Renderer on either of the APIs.

I can confirm that the solution @ichee suggested removes stutter completely: Changing FramerateNTSC to 60.00 in PCSX2_vm.ini completely eliminates stuttering. With this change, the reported FPS and Gamespeed are stuck to 100%/60 fps (well 59.9x to 60.0x) respectively.
However, I have not tested this long enough to see if it results in some timing or other emulation issues (the game is, after all, running slightly faster).

I tested all this with Silent Hill 2 (which, I believe, runs at 30fps on original hardware), while keeping VSYNC off and Aspect Ratio to Standard in the PCSX GS Window settings.

My System:
Ryzen 3900X
Nvidia RTX 2060 (Driver 461.40)
Windows 10 Pro

[MrCK1]

I can confirm the stuttering issue on both PCSX v1.6 and the latest pcsx2-v1.7.0-dev-944-g7c072094a-windows-x86.

I can however not confirm that the issue is only visible with OpenGL. While different, I am observing some stutter with the D3D Renderer aswell. This also exhibits in somewhat erratic jumps of reported FPS/Game Speed in the PCSX Window (Game Speed jumps between 99% and 101% while FPS varies from 59.9x to 60.7x. The issue is actually also present when using the Software Renderer on either of the APIs.

I can confirm that the solution @ichee suggested removes stutter completely: Changing FramerateNTSC to 60.00 in PCSX2_vm.ini completely eliminates stuttering. With this change, the reported FPS and Gamespeed are stuck to 100%/60 fps (well 59.9x to 60.0x) respectively.
However, I have not tested this long enough to see if it results in some timing or other emulation issues (the game is, after all, running slightly faster).

I tested all this with Silent Hill 2 (which, I believe, runs at 30fps on original hardware), while keeping VSYNC off and Aspect Ratio to Standard in the PCSX GS Window settings.

My System:
Ryzen 3900X
Nvidia RTX 2060 (Driver 461.40)
Windows 10 Pro

Did you try a 1.7 build without the framerate limiter modifcation?

We had several users with prior input lag issues reporting no problems on 1.7 builds without other modifcations needed. There were several changes done to the framelimiter code that should elimintate those small spikes over 59.94.

[clang88]

Did you try a 1.7 build without the framerate limiter modifcation?

We had several users with prior input lag issues reporting no problems on 1.7 builds without other modifcations needed.
There were several changes done to the framelimiter code that should elimintate those small spikes over 59.94.

I tried the 1.7 build I mentioned (pcsx2-v1.7.0-dev-944-g7c072094a-windows-x86) first without any modifications and had stutter and jumping frametimes. Do earlier 1.7 builds behave differently? Would you mind pointing me to a build that should behave correctly?

[refractionpcsx2]

Did you try a 1.7 build without the framerate limiter modifcation?
We had several users with prior input lag issues reporting no problems on 1.7 builds without other modifcations needed.
There were several changes done to the framelimiter code that should elimintate those small spikes over 59.94.

I tried the 1.7 build I mentioned (pcsx2-v1.7.0-dev-944-g7c072094a-windows-x86) first without any modifications and had stutter and jumping frametimes. Do earlier 1.7 builds behave differently? Would you mind pointing me to a build that should behave correctly?

are you using VSync in PCSX2 or forcing VSync in your GPU driver by chance? because that could cause microstutters

[clang88]

I was doing neither, although I am using windows 10 which, I think, forces triple buffered VSync on everything but exclusive Fullscreen

[refractionpcsx2]

Triple VSync? Do you mean Triple Buffering? You can turn that off in your GPU driver (at least with Nvidia), however PCSX2's frame limiter shouldn't exceed the time per frame to let you queue up frames like that.

Also I'm using Windows 10 and it doesn't force VSync on for me, that's done at GPU driver level.

[Nicholas-Steel]

The Triple Buffering option within the Nvidia Control Panel only affects OpenGL, it does not affect DirectX.

[clang88]

I just retested it all. Running up and down in the beginning of silent hill 2. Vsync is set to application controlled in nvidia control panel (in fact, it is all default there); Vsync is disabled in PCSX 2. I'm using the "Safest" Preset with only the Multi-Core hack enabled (although I have observed the same issue with it disabled). For GS emulation I use the software renderer with 4 threads and everything enabled. pcsx2-v1.7.0-dev-944-g7c072094a-windows-x86

I also disabled any kind of overlay (steam, rivatuner) to be sure, that there is no interference.

Running at the default 59.94 Framelimit the game would periodically start stuttering, kind of like it needs to smooth out the accumulated missing frames. At 60.00 nothing, it runs smooth the whole time, never once stuttering.

@Nicholas-Steel has made a perfect video demonstrating the issue. I'm not sure it is the same issue as for me, because as I said, setting Framerate to 60.00 pretty much solves the stuttering issue in my case. If needed, I can make a video of my tests as well, or try some other things. Just let me know. Nicholas-Steel's post: #issuecomment-678797517

[refractionpcsx2]

It's unlikely we're going to bring WS_POPUP back, but there is a PR #3549 which changes DX to the flip model which is likely similar to what WS_POPUP was using, so you will be able to use that. Of course you will likely get tearing but you can't have a nice smooth picture that's synced with your display and have it run at the correct framerate, that's two completely incompatible things.

With the PR mentioned above it supports technologies such as Freesync or Gsync, and from my testing that seems to remove any stuttering/tearing I experience without the tech.

A Good way to test for stuttering/tearing is to use Pillgen which I have attached here, you can watch the white box along the top

pillgen-60fps-ntsc.zip

[jeremybris]

Stuttering has been mitigated by the Vulkan Render, for me. (My vm.ini, NTSC refresh rate is changed to 60 fps.) Anyone else?

[refractionpcsx2]

Should be fine in other renderers too since the GS window has been replaced with the host interface, so I don't believe it's using WX anymore (which was a problem)

[F0bes]

Closing for the reason stated in the above comment.

[mirh]

https://wiki.special-k.info/Presentation_Model#bitblt-d3d11
https://www.pcgamingwiki.com/wiki/Windows#Fullscreen_optimizations
Ok, long time no see, but after much.. uh, investigations, I think I have an actual half-way complete picture.
Pretty much everything that I had always imagined was true - just like I suppose pretty much anything the "not my monkeys, your problem" camp was guessing was more or less right too. In the process of writing this I even found tons of conundrums undocumented anywhere else.
The following tries to explain why dx11 was already just *good* for some, while others could have sworn on their sons it sucked hard.

Of course the worst experiences might have been due to bugs (random examples), but that alone would have been too simple:

• fullscreen optimizations promote apps to the flip model (which should give smoother results with DWM, even if not up to FSE)
• between 1607 and 1709* those applied to windowed and borderless modes (and hence pcsx2 which never had FSE) too
• even afterwards, we got included in a "games" whitelist (which I haven't comprehended yet, but let's say ½ of times it forces flip)
  • yes, MS noticed us (so much so that somehow they even include names going as back as custom wx builds of 0.9.7 betas)
• since W10 ~1607 directflip/iflip is a thing too, meaning you LEGITIMATELY might get FSE-like immediate 0 latency fullscreen**
• on top of that, more or less all laptop igps since late 2015 support multiplane overlays***. Meaning that a sizeable chunk of tests was coming from systems where *even windowed mode* could be just as good as literal DWM off.

All the while stuff like optimus, multi-monitor, HAGS and VRR could have added even more variance and complexity to the picture.
And this ladies and gentlemen is our story. The crazy thing is that it could have been figured out much sooner if somebody had just used PresentMon.

*these may sound forgettable today, but take notice that's sitting more or less in the middle of the hottest phase of this drama
**provided fit to screen is used, similarly to the GL FSE hack (idk how much that's a wx quirk rather than expected behaviour, but still)
***desktop gpus have them too now, but as this problem was winded down by ~2021 it shouldn't matter for this explanation

[clang88]

Super interesting read, thx! It's always those little things that just add up and no one seems to care, but evidently someone did care :) I must say that since PCSX 2.2.0 I have not experienced the kind of stutters anymore, especially with the various options for framepacing introduced.

[mirh]

The mystery was actually a bit more over the reason different people were reporting such wildly different results (in terms far too grandiose for even the most noobish suggestive placebo), than about "technical improvements that ideally would be neater to have".
I mean.. I'll grant that in my little ted talk above I still haven't pinned down this to something 100% specific, but pretty much any search of FSO is mired by old stories of people grasping at straws for their excruciating lag and be finally relieved after disabling it.

Flip presentation was eventually implemented in #5221 (aka v1.7.2187) anyway, on top of newer drivers and windows evening the playing field and most "blemishes" by ~2022 too. Stuff like #3785 was imho kinda a red herring ironically, given the root hitch.
So.. I believe the only scenario which is still potentially subpar is windowed opengl and vulkan, when they aren't getting DXGI presentation forced by the driver (#6145 didn't seem to make adding interop features much appreciated, but who knows the future)