Pcsx2: Get WS_POPUP back

Created on 30 Aug 2017  路  38Comments  路  Source: PCSX2/pcsx2

Either by reverting to before 234bf8af34f1f88be275deb3a4a0673006caaccb, or making EnableVsyncWindowFlag true by default.

Fixes whatever was originally actually reported in #1437 - if then somebody else experiences any problem (something dwmflush madness something) he'll be free to open yet another issue.

Most helpful comment

I was missing some runtimes, so I made my own. XD

All 38 comments

Ain't WS_POPUP supposed to be the style on fullscreen? "new_style = WS_POPUP" as opposed to "new_style |= WS_POPUP".

#EDIT: There's EX_TOPMOST too while at it.

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.

I thought it was just a weird issue but it appears to be way more convoluted than that. I can't help but I in one of my test programs the fullscreen code doesn't use WS_POPUP. Thus, I turned it into a simple tearing test, might be of use... perhaps.

#EDIT: Forgot some usage keys.

F1 = Fake full screen
F2 = Exclusive full screen to 1024 x 768

Numpad + = SwapInterval + 1
Numpad - = SwapInterval - 1

tearing_test.zip

Cool, that's really nice.
It also makes for a perfect test case of adaptive v-sync.
(and I guess it's way more usable than mine in wx)

I can report 0 problems on my AMD then.

I was missing some runtimes, so I made my own. XD

@mirh Do you still have issues relating to WS_POPUP or are we all set here?

What?
I wasn't the one with the problem.
This was just a TL;DR from #1437 for somebody to quickly (wrongly in retrospect) fix it.

@RAZORXKHARA33 reported that to solve his stuttering, and I couldn't call it a better day after almost 300 comments.

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.

Yes, I know it was done to avoid tearing.
But might I suppose that was due to our broken opengl implementation of the thing in the first place?
EDIT for below: yes we know

I haven't noticed any issues with tearing, seems ok. not sure about AMD cards...

@turtleli Could you test stuttering on Win/Nvidia with EnableVsyncWindowFlag=enabled ?

Do you mean tearing or stuttering? IIRC enabled = potential tearing, disabled = potential stuttering?

IIRC enabled = potential tearing

As I said 99 times, until gregory fixed it months ago, we had broken v-sync ourselves.
Then, I guess also drivers play an important role in this equation, but I learned to stop speculating over that.

In the meantime *at least* fixing stuttering is a reliably reported effect.

until gregory fixed it months ago, we had broken v-sync ourselves.

Do you mean #2049?

Ugh.. Maybe you are right.
...
Anyway, I'm not sure how much difficult it would be to just try and see.

Yes, I didn't do anything....

@turtleli You're right, I mean tearing. I just want to be sure it's still as bad as before.

With the flag enabled:

  • Vsync disabled - tearing
  • Vsync standard - no tearing
  • Vsync adaptive - tearing (but less than disabled)

Which is what I expect.

(NVIDIA GTX970, Windows 10, drivers 385.69 and 388.13, using Super Robot Wars OG: Original Generations as my test case)

Thank you for testing.
So.. Back to my point, I think WS_POPUP should be reinstated?

p.s. adaptive observation is pretty interesting. Are we talking about an ntsc game on 60hz monitor?
EDIT: interesting for other vsync considerations, OT to this thread

p.s. adaptive observation is pretty interesting. Are we talking about an ntsc game on 60hz monitor?

I don't see how the adaptive result is interesting? The result is normal and expected. Game is NTSC-J (title on DVD case is 銈广兗銉戙兗銉儨銉冦儓澶ф垿OG Original Generations), monitor is 60Hz.

So.. Back to my point, I think WS_POPUP should be reinstated?

Dunno. I think OpenGL exclusive fullscreen means having to deal with fun driver behaviour (I think #820 and #1312 are related). Personally I'd prefer there being an option to choose between borderless fullscreen and exclusive fullscreen without modifications to wx (maybe by having a 1 pixel border for borderless fullscreen or some other way that avoids exclusive fullscreen on both AMD and NVIDIA) (EDIT: Kinda forgot that exclusive fullscreen has specific criteria, which just further complicates this).

Kinda forgot that exclusive fullscreen has specific criteria, which just further complicates this

Yes, that's the problem.
So far, imo, the biggest "priority" if any, should be having consistent intel/amd and nvidia behavior.
Then, once we have that, I believe it should be quite a cakewalk to quit exclusive fullscreen given all the underlying conditions you can tinker with (e.g. what you said, or even creating the window with PFD_DOUBLEBUFFER_DONTCARE in my testings)

Then, truth be told, alt-tabbing is so fast in pcsx2 (even starting from exclusive fullscreen), that I don't see even a point in caring about borderless, rather than exclusive.
But I'm not necessarily opposing having this choice, nonetheless.

Then, truth be told, alt-tabbing is so fast in pcsx2 (even starting from exclusive fullscreen), that I don't see even a point in caring about borderless, rather than exclusive.

Because exclusive fullscreen issues are annoying to deal with? And as I said earlier

I think OpenGL exclusive fullscreen means having to deal with fun driver behaviour (I think #820 and #1312 are related)

such as pressing F12 to start recording, only for the GSdx recording dialog box to not show up unless I alt-tab so it loses and regains focus.

What about just disabling dialogs, ect in fullscreen excusive?

Why? And how would that even work? That's not even the only possible issue with exclusive fullscreen (#1312 hints at exclusive fullscreen causing a crash).

Because exclusive fullscreen issues are annoying to deal with? And as I said earlier

Couldn't have they been resolved?
Here are some nice test-case steps. And I can't believe that for once I even have the game in question.
I may do some testing once I find the time (though, refraction already couldn't trigger the issue..)

p.s. maybe we should start to keep a list of the dirty drivers workarounds?
p.p.s. shouldn't automatic aspect ratio switching be always preferable regardless of crashes for FMVs?

such as pressing F12 to start recording, only for the GSdx recording dialog box to not show up unless I alt-tab so it loses and regains focus.

That.. seems something broken on our end I think?

Here are some nice test-case steps. And I can't believe that for once I even have the game in question.
I may do some testing once I find the time (though, refraction already couldn't trigger the issue..)

It's not game specific? Refracton - NVIDIA, FlatOut - AMD. Maybe the crashing is fixed, maybe it isn't.

That.. seems something broken on our end I think?

Only happens when exclusive fullscreen is triggered.

So... Just tested (both gcn and pre-gcn).
It doesn't crash for me.
...
It simply seems to _hang_ on switch. Not 200% it must be *necessarily* driver specific.
I'd even try to give some more insight then, but I accidentally attached vs debugger to dwm and now I have worse problems to figure out.

Only happens when exclusive fullscreen is triggered.

_Yes_, but I don't see why this should be the case. Dialog is ours, we have total control.
Wouldn't like spawning it TOPMOST or something fix it?

It simply seems to hang on switch. Not 200% it must be necessarily driver specific.

That's likely a different issue (#1189).

Yes, but I don't see why this should be the case. Dialog is ours, we have total control.
Wouldn't like spawning it TOPMOST or something fix it?

Because the usual rules don't apply during exclusive fullscreen. The driver is interfering and enforcing whatever behaviour it wants. We don't have control in this situation (like #820, game window froze instead of you know, closing properly. Total control - I don't think so).

And I doubt WS_EX_TOPMOST will fix it - I ran MPC-HC with Always on Top enabled alongside PCSX2 and OpenGL exclusive fullscreen was on top. The usual rules do not apply.

That's likely a different issue

Well, then I have no crashes.

And I doubt WS_EX_TOPMOST will fix it - I ran MPC-HC with Always on Top enabled alongside PCSX2 and OpenGL exclusive fullscreen was on top. The usual rules do not apply.

You seem right.
What if we try SetFocus or SetActiveWindow on recording dialog creation then?
EDIT: other ideas
EDIT2: snippets

What if we try SetFocus or SetActiveWindow on recording dialog creation then?

I don't expect it to work? You can try and see if it works.

I don't expect it to work?

Well, how alt-tab would work otherwise then? That was my rationale.
I mean, pcsx2 window is still in the background and others can get in front of it normally, so there must be a way.

Well, how would I know? The usual rules don't apply. Go try whatever you think will work and see if it works.

Obviously I forgot to answer. Thanks you for the test.

I agree with turtleli. Exclusive fullscreen is outside of any spec/standard behavior. Besides I suspect exclusive fullscreen isn't compatible with multi-screen.

I think, the best we can do is to have an option (with various warning) so user can select the behavior. (Note: I won't call my wx hack an option).

Exclusive fullscreen is outside of any spec/standard behavior.

Yes, and it's driver business.
WX_POPUP was supposed to be there and we just removed it.. To """ fix """ v-sync.
I don't think adding it back again should be that considered all that fuck of hacking the system.

I agree with turtleli.

? He said that exclusive would be responsible for triggering 2 other changes.
I addressed one, as another bug we have nonetheless.

While the second, for as much as having a not-so-clear solution, is pretty duper minor if you ask me.

Besides I suspect exclusive fullscreen isn't compatible with multi-screen.

What? That's why you have eyefinity, surround and such, isn't it?
Otherwise, I'm pretty sure window behavior is already (regardless of anything) to just maximize to the \ screen.

Besides, besides, besides.. Do we remember this is about fixing nvidia driver stuttering behavior?
It would be quite bad if this introduced crashes for the other vendors. But.. What's the actual problem here? That for the moment if you want to start recording, you'll have to reach your mouse to double click the window?

Stupidest idea: can't we just re-add window border when \ is called?
Then, if user has never lost focus with this last one, on closure switch back to borderless/fullscreen.
Else don't to anything.

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

I'd love Fullscreen Exclusive mode, so much better than the various issues caused by the DWM. If the program crashes in a way that prevents other programs from appearing over the crashed application window than that is handled by setting Task Manager to "Always on top" mode before opening PCSX2, which anyone using Fullscreen exclusive mode in _any_ application should be doing as it allows the Task manager to appear over programs that have crashed in such a manner.

While Fullscreen Exclusive mode may not be standard even though it's worked fine 99.99% of the time for decades (oh no, Alt Tab is slightly slower! the horror!), it handles frame presentation a lot better than whatever the Windows DWM does to the majority of programs not carefully/correctly programmed to work with it.

Sorry, it's just that a lot of people seem to absolutely hate Fullscreen Exclusive and wish it would vanish from existence even though it's entirely optional in most programs... they tend to think that the slower Alt Tab performance is super scary and that no sane person could tolerate the less than a second delay (some programs took longer to return to the game because they'd unload assets if they were in Fullscreen and you multi-tasked away).

Exclusive fulllscreen does not really exist by itself on modern windows, it is under the umbrella of FSO (fulllscreen optimizations).

If you could post your specs as to what's you're running and/or test data to backup your claims, it would be a bigger help.

Fullscreen Optimizations can be disabled but Microsoft will no doubt get rid of that compatibility option at some point which will be a dark day for old/unmaintained video games.

I've explained my issue in this forum thread: https://forums.pcsx2.net/Thread-Frame-Pacing-Problem-not-FPS-related

Was this page helpful?
0 / 5 - 0 ratings

Related issues

backgamon picture backgamon  路  5Comments

mcabel picture mcabel  路  4Comments

Javed-Iqbal-1 picture Javed-Iqbal-1  路  5Comments

Levan7 picture Levan7  路  3Comments

mirh picture mirh  路  6Comments