Pcsx2: 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 https://github.com/PCSX2/pcsx2/issues/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 cpugpu 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...

https://github.com/PCSX2/pcsx2/issues/1437#issuecomment-301492954

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.

[gregory38]

Why ? It shouldn't be an issue. Game size&mode are accessible in gs side

[mirh]

Yes but if you lock surface to window this way, and then you have surface that only expands by multiples..
Doesn't that also pass to window then?
...

Anyway, considering all of this oddness, an "nvidia anti-stutter paranoia" button that enable DWMFlush is the only possible fix that can manage to cover *all* the possible situations imo.
I am sorry for all the wasted time my crawling for a "programmatic" solution caused.

[thatsage]

Just thought to update since I'm playing Rogue Galaxy atm. This is relevant on b6a73f6 (4 days old svn as of today).

Under normal circumstances OpenGL and DX11 both go into prolonged micro-stutter every 15-30 seconds, and the micro-stutter lasts a period of ~3 seconds. I am pretty sure that previously it didn't happen in DX11, not with Shadow Herats, but with Rogue Galaxy DX11 exhibits the same problem.

As expected changing EnableVsyncWindowFlag to enabled and then going full-screen 16:9 completely fixes the issue (both in DX11 and OpenGL).

I may be imagining this, but it feels like this change also increases input lag.

[mirh]

So, you are telling us that D3D11 here has no problem whatsoever, while here it lags stutters (without ws_popup)?

[thatsage]

If by lag you mean stutter, they both do. Both builds stutter on DX11 and OpenGL both without ws_popup. I think back then when I tested the ws_popup flag first what might've happened is that I probably forget to reset it to disabled when I tried DX11 and that's why I thought DX11 didn't have this problem.

I'm sorry for making it so confusing.

To summarize: both builds exhibit the same problem which can be fixed the same way. Regardless of DX11 or OpenGL, without the ws_popup flag (and playing in fullscreen 16:9 or streched) games stutter. This change does also introduces tearing, which NVCP or PCSX2 forced vsync resolves.

To my amateurish self it just seems like when DWM "takes over" and applies its own vsync solution to the end result (which ws_popup and full-screen seem to forbid it) it's fucking up the frame-pacing of what's being displayed. I think it's important to note that without this change, it's impossible to get tearing no matter what, further showing that it's DWM messing things up by forcing it on the end result.

Let's say I turn off the frame-limiter, and since there's no vsync or anything like it, like with any game then normally we will get tearing in full-screen. But in window mode because of DWM choosing which frames to display, throwing the others to the trash, we get visual stutter because it doesn't seem to care what goes on in that window (in terms of its frame-rate or frame-pacing).

[mirh]

Is stuttering also a thing in dx9?
And could you try 1.4.0 (aside of fullscreen, which should trigger there afaik)?

[thatsage]

dx9 stutters the same

1.4.0 - OpenGL doesn't stutter. dx9 and dx11 do.

nothing changes between windowed and full-screen

[mirh]

So.. to clear again: d3d stutters everywhere.
Opengl is either working specifically if you met all the criteria (WS_POPUP, fit-to-screen, fullscreen) in latest git .. Or unconditionally always in 1.4.0?

[thatsage]

Almost hehe.

The fix works for D3D too, everywhere. But as you said, OpenGL on 1.4.0 doesn't require the fix and is working fine unconditionally.

[mirh]

Can you try this?

[thatsage]

Stutters like the other revisions (besides the 1.4 one on OpenGL).

Thank you for trying to get behind this so much btw :) I hope we get to the bottom of it.

[mirh]

Problem is, we are screwed now.
I was as always hoping some dumb blind bisecting could be done, but there is this sea of commits that one has to build oneself too now.

Unless you are.. Cool with using VS, I guess I'll have to put on hold ideas for the moment.

[mirh]

Could you please try driver 375.63/disable telemetry/clean standby memory?
https://www.askwoody.com/2018/stuttering-reported-with-win10-nvidia-geforce-gtx-10xx-cards/

[thatsage]

Are you sure this can be relevant? I have a Maxwell card (970) and the stutter isn't system wide, and we found ways to resolve it completely by changing pcsx2 configuration while nothing in windows or drivers mattered. With 1.4.0, OpenGL didn't have the problem at all too, so it really seems to be PCSX2 related

[mirh]

It *clearly* is something nvidia-driver-related, if a totally innocent flag triggers stuttering.
We (kind of) understand what's the trigger on the application side, but dreaming of a precise answer from nvidia devs, I'd like some analysis on their side now.

[mirh]

@thatsage great news boi
I just now realized, the wayback machine has all the old names archived.
And the links are still live and all.
Could you therefore try to bisect which 2016 release changed everything?

[aidenn]

Hi, user side here. Does this flag (EnableVsyncWindowFlag=enabled) actually make anything worse for AMD users? If not, then maybe, for the time being, it should be on by default?

I had a clean Windows 10 reinstall the other day, booted up pcsx2 and whoah, stuttering. WAIT, I REMEMBER SOMETHING ABOUT VSYNC AND 16:9. Nothing. After 30 minutes I remembered, wait, wasn't there a flag in the ini or something?

I know that this is a driver issue (actually, last year, even this flag couldn't help me until I updated the drivers, so nothing helps if you're using drivers older than ~summer 2017), but if the flag isn't making things worse, then maybe it's better to enable it by default?

PS. Did you hear about that latest craze called beam racing? Is it possible to implement it efficiently in pcsx2?

[mirh]

No, it doesn't have any downside at all with amd.
The problem for the thing not being enabled by default is that: 1) the exclusive fullscreen you hence trigger, causes us some headache 2) it still seems like we are missing something of the bigger picture.. I mean, what to do with windowed mode then? 3) 0.01% OF PEOPLE ACTUALLY HELP WITH TESTING

...
So, long story short, for the moment the only thing I'd advise nvidia users to do, is to roughly bisect this range of commits from the releases named here - and report back where you find this bad behavior was introduced.
(protip: copy paste the urls of the releases, and remove anything before https://buildbot.orphis.net for faster downloads)

[aidenn]

Thanks for that issue you linked, it was a missing link in my understanding of the case. And 3) I am quite helpful, if you want, I can test anything you send me (2500k@4Ghz, 760 gtx, win10). And that means that I will test these commits, But that will have to wait until two days from now (work reasons), but I did encode it both in my brain and in my schedule and it isn't any kind of difficult, so please give me a couple of days (+2) and I'll check exacty which commit did this.

I can also test linux, because that's my system of choice on my laptop, but it can't hold 60 fps in even the simplest of games, so I doubt it would be useful in this case.

[aidenn]

Okay, a couple of days turned into a month, damn that RL, but I finally sat down to check this out. It only took 32 builds to find, so it wasn't that bad.

Methodology: run Legend of Saiyuki AKA Heavenly Guardian (since it's 60 fps, not demanding and loads fast) and run left and right for a few minutes.

The last build with smooth scrolling is 375 (although 4:3 stutters in all builds, so stretch to window/screen is mandatory). The next available build (379) stutters no matter what I set.

I guess it's just this commit after all: https://github.com/PCSX2/pcsx2/commit/234bf8af34f1f88be275deb3a4a0673006caaccb

-- edit --

And no, there's no tearing either beginning with 1.4.0 and ending with 375. Maybe whatever caused the tearing before was due to older nvidia drivers?

[mirh]

Yes.. It must be that commit
And we are back to square one...

What renderer did you use? @thatsage said dx was stuttering even on 1.4.0
And turtleli reported tearing not so much ago.

[mirh]

I was told forceware 4xx-something would be super duper gold.
Anybody that could test this?

(and I wonder if this isn't the same issue libretro has)

[mirh]

Bump for people that should actually get out testing this
Link dump for developers with time to spare
https://bitbucket.org/pyglet/pyglet/issues/169/windows-windowflip-too-slow
https://stackoverflow.com/questions/45676892/reliable-windowed-vsync-with-opengl-on-windows
https://github.com/glfw/glfw/issues/649

[OCRBonk]

FWIW I am able to get basically stutter free video by using RTSS Scanline Sync in Windows 7 with Aero disabled in OGL Hardware.

Vsync and the internal Frame Limiter have to be disabled. Otherwise you cannot get a stable tearline hidden and you will get a rolling tearline instead. Scanline Sync will act as limiter instead.
I use CRU to create a custom refresh rate of 59.94, use TestUFO.com and the display overclocking test and the Refresh Rate detector to ensure everything is working correctly.

Scanline Sync is set to the appropriate line. (In my case a 1080p display, line 1124).
And Sync Time Out is set to 16.683ms (written as 16683 in the config)
1000/59.94=16.683xxxx
Using 1:1 SS seems to even work stable here for 30hz interlaced games like Front Misison 4. No stutter. (Aside from loading here and there)

After quite a bit of trial and error this seems to finally, be pretty much stable. I decided to test this after buying a few games I already own for the PS4 emulated versions on PSN and was highly disappointed at the performance in several games having drops or heavy recurrent stuttering (Star Ocean 3 , Arc the lad for example)

This same set-up is also exactly applicable to PPSSPP using DX9 but i'm sure it works in others too. Why use DX9? So you can force Anti Aliasing from the driver for Nvidia cards
No AA https://abload.de/img/ppssppwindows64_2019_p9kd5.png
8xSGSSAA forced using 0x084012C1 in Nvidia Profile Inspector https://abload.de/img/ppssppwindows64_2019_qbjm4.png (Texture aliasing begone!)
There are zero visual glitches i've encountered thus far because of this other than having Vertex Cache enabled causes a few polygons to become sporadically invisible in Metal Gear Ac!d. Disabling it fixes the problem with no performance hit.

This gets stutter free 30hz Vsync (except you use 1/2 Scanline Sync.) Unless it's a mixed framerate game that does menus at 60hz, then the 30hz elements aren't quite as stable. But this has been the biggest issue for using PPSSPP for me for years. No exclusive fullscreen, horrible frame pacing. PPSSPP on android runs a lot of games i'd like to play on a Droid 2 turbo at 1440p internal resolution. But even there the frame pacing is bad.

Using the RA PPSSPP core can be hit and miss but you can also get perfect 30hz sync in that as well by using Vsync interval =2, which will give you 1/2 refresh sync. (But not on android)

My hardware for reference.
R5 2600x 4.2Ghz
RTX 2080
16GB DDR3
W7/10 dualboot
Buncha HDDs/NVM/SSDs, PCSX2/PPSSPP running off a mechanical drive though.

[mirh]

So... I don't doubt that the most smooth, performant solution is having your screen refresh match the emulation one and all, see #2059

But as already said 999 times in this thread, and the problem we are trying to address, is that users with damn nvidia cards shouldn't have to do anything at all to have a "decent enough" experience. Instead, we have this special window flag with still no rationale about its reasons to exist.

[OCRBonk]

I only set the refresh rate to that to cover all my bases. Even with the refresh rate set to 60.000 it seems to work pretty much just fine too as long as I disable the framelimiter and let SS limit instead.

For me without a Full Screen Exclusive mode, the only acceptable way to get vsync is to use Aero in W7 and that causes massive input lag and horrible frame pacing.
(Where as in emulators with a FSE mode, like the RA core of PPSSPP and the ability to set 1/2 refresh rate Vsync fixes the problem too in that emulator. Just as you have to do in order to get proper 30hz Vsync in any modern PC game on a 60hz display without stutter/frame pacing problems. And that applies to any GPU vendor. )

PPSSPP has the same problem.(No FSE available) Scanline Sync fixes these issues.
I'm used to having to tweak a ton of stuff for PC games on Nvidia so it doesn't bother me as much. But in the decade i've been following off and on development of PCSX2 this is the first time i've ever been able to get an ideal Vsync/ Input lag/Frame pacing scenario without huge issues. And that alone makes me pretty happy.

[mirh]

For me without a Full Screen Exclusive mode, the only acceptable way to get vsync is to use Aero in W7 and that causes massive input lag and horrible frame pacing.

And this entire thread is about telling you there must be something really concerning going on with the nvidia driver.
Because for as much as "normal 60hz aero" may not be perfect, it's anything but horrible and outrageous on my normal humble amd card. *Even with PAL games*

And I'd like to underline you again that you seem to have missed the fact that FSE can be very easily enabled with EnableVsyncWindowFlag=enabled ini option.

[BParks21]

Can we get a gui option to enable EnableVsyncWindowFlag=enabled from the settings menu. I just did a clean install of PCSX2 and completely forgot about this setting needing to be set in the .ini file and was going mad trying to remember why my games were stuttering again and what i had to find to fix it.

[mirh]

I'm almost happy nvidia users have to go through the hassle.
Perhaps one day it may be enough for somebody to bother so much to help investigating it. After 3 years, it feels like I'm the person having cared more about this.. And I don't even own the affected hardware.

Also, as a fun fact, it seems like there might be another "principle of stuttering" somewhere between W10 or nvidia drivers.

[BParks21]

FWIW I am able to get basically stutter free video by using RTSS Scanline Sync in Windows 7 with Aero disabled in OGL Hardware.

Vsync and the internal Frame Limiter have to be disabled. Otherwise you cannot get a stable tearline hidden and you will get a rolling tearline instead. Scanline Sync will act as limiter instead.
I use CRU to create a custom refresh rate of 59.94, use TestUFO.com and the display overclocking test and the Refresh Rate detector to ensure everything is working correctly.

Scanline Sync is set to the appropriate line. (In my case a 1080p display, line 1124).
And Sync Time Out is set to 16.683ms (written as 16683 in the config)
1000/59.94=16.683xxxx
Using 1:1 SS seems to even work stable here for 30hz interlaced games like Front Misison 4. No stutter. (Aside from loading here and there)

After quite a bit of trial and error this seems to finally, be pretty much stable. I decided to test this after buying a few games I already own for the PS4 emulated versions on PSN and was highly disappointed at the performance in several games having drops or heavy recurrent stuttering (Star Ocean 3 , Arc the lad for example)

This same set-up is also exactly applicable to PPSSPP using DX9 but i'm sure it works in others too. Why use DX9? So you can force Anti Aliasing from the driver for Nvidia cards
No AA https://abload.de/img/ppssppwindows64_2019_p9kd5.png
8xSGSSAA forced using 0x084012C1 in Nvidia Profile Inspector https://abload.de/img/ppssppwindows64_2019_qbjm4.png (Texture aliasing begone!)
There are zero visual glitches i've encountered thus far because of this other than having Vertex Cache enabled causes a few polygons to become sporadically invisible in Metal Gear Ac!d. Disabling it fixes the problem with no performance hit.

This gets stutter free 30hz Vsync (except you use 1/2 Scanline Sync.) Unless it's a mixed framerate game that does menus at 60hz, then the 30hz elements aren't quite as stable. But this has been the biggest issue for using PPSSPP for me for years. No exclusive fullscreen, horrible frame pacing. PPSSPP on android runs a lot of games i'd like to play on a Droid 2 turbo at 1440p internal resolution. But even there the frame pacing is bad.

Using the RA PPSSPP core can be hit and miss but you can also get perfect 30hz sync in that as well by using Vsync interval =2, which will give you 1/2 refresh sync. (But not on android)

My hardware for reference.
R5 2600x 4.2Ghz
RTX 2080
16GB DDR3
W7/10 dualboot
Buncha HDDs/NVM/SSDs, PCSX2/PPSSPP running off a mechanical drive though.

I can confirm what OCRBonk has done works. Same for the swap interval in Retroarch.

[mirh]

Is that working any worse or better than EnableVsyncWindowFlag=enabled ?

[BParks21]

Technically better. RTSS reports are flawless 16.6ms frametime when limiting the framerate to 60fps in combination with the flag option. There is no devation in this frametime accept in screen transitions which is normal. Visually there is no difference in doing this as opposed to using the flag option alone. However without limiting the framerate in combination with the flag option the frametimes are less stable fluctuating between 16.7ms, 17ms and sometimes randomly jumps to the 40's! Strange that when only using the flag option never results in 16.6ms. Here are some screenshots. I had to take them in window mode because i couldn't capture them correctly in fullscreen, but this did not effect frametimes.

[mirh]

... wait a moment
Why do you have those black bars on the sides of the window?

[MrCK1]

He might be using the "Full" BIOS settings instead of 16:9, some games depend on it for aspect ratio

[Dreadmoth]

That's just how a 16:9 output fits between the title bar and taskbar with the PCSX2 window maximised - if it occupied the full width it'd be stretched (or cropped).

[vsub]

Yes,that's how 16:9 look like on 1920:1080 in window mode(not just on pcsx2)
In fullscreen those black bars are gone

[mirh]

Uh, crap.
Could you try to use fit to screen then instead?

[BParks21]

Sure, fit to screen window mode fine? I'm unable to properly capture the overlay in fullscreen.

[mirh]

I meant: do you get a smooth image with that and the vsync flag instead (which.. are you putting inside PCSX2_ui btw?)?
Because it already happened that destroyed perfection.

[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: https://github.com/PCSX2/pcsx2/issues/3571