Toggle full screen is buggy [Windows OS, Intel GPU]

[ClubIce]

Since 0.9.8-649, when you toggle from window mode to full screen and return to window mode again, this lock the screen and sometimes doesn't let close the emulator.

last working build: 0.9.8-646

[RadarNyan]

Can't reproduce on latest git build (v0.9.8-1144, default settings) on Windows 7 x64 with any of my games.

[ClubIce]

try it using ALT+ENTER in PPSSPP main menu

[RadarNyan]

Forget to mention, not only in-game, can't reproduce on any scene (main menu, settings, etc)

[Bigpet]

Sounds like a driver bug to me (I mean the commit 281ff6c is obviously what triggered it, but I wouldn't revert it just yet). Can't reproduce either. Does this happen every time for you? And does the emulator crash or are the window controls just unresponsive?

[ClubIce]

[Bigpet]

If it crashes can you use a debugger and find out where it crashes?

[ClubIce]

the emulator doesn't crash, simply image is wrong, i try take a screenshot, but this only show a black screen

[thedax]

It might be an Intel graphics-only bug/issue.

[RadarNyan]

Confirmed on my laptop, intel HD4000 Windows 7 x64.
However it didn't freeze on my laptop, the screen size is back to windowed size but doesn't seems returning back to PPSSPP window - The window-sized PPSSPP is still running in full screen with the screen displaying at the lower left corner and the rest part of screen is a dark blue color. However I can "see" the PPSSPP window by putting my mouse at the PPSSPP window border position ant it will become resize style.

[agent13]

I have same problem... Intel HD4000 Windows 8 x64

[ClubIce]

this issue is still in latest builds, should be fixed before launch 0.9.9 because this is an important regression.

[hrydgard]

Trying some stuff.

Even without it though, fullscreen toggle and back works flawlessly on my system (nvidia GPU).

[thedax]

I have a laptop I'm borrowing from my mother and I can reproduce it too. @hrydgard: I'll see if your latest commit fixes it.

[pal1000]

For me it didn't make any difference:

[hrydgard]

thedax is messing about with it.

Last resort I'll just revert the offending commit. I actually thought it would increase compat, not decrease it...

[thedax]

I'll work on it more in a day or so, I'm not having much luck.

[thedax]

Bleh, I doubt I'll have this fixed in time for 0.9.9, feel free to revert the inner window removal, I guess.

It's definitely something in PPSSPP, though. I made an SDL2 OpenGL accelerated window (as a sample separate program) and had no problem entering and exiting fullscreen with it, on this Intel GPU laptop.

[unknownbrackets]

It seems like the stride is wrong or something. Is it permanent? Like if you select a new window size? Does going info a game fix it / does it happen while playing or menu only? Does changing render resolution affect it?

Does it work again when switching back to fullscreen?

Does minimizing and restoring the window affect it?

-[Unknown]

[thedax]

If you're asking me, it works as follows on my mother's laptop:

Is it permanent?

No. If I edit the ini to make PPSSPP use window mode again, it shows up fine. If I then enter fullscreen and try to revert back to windowed mode, it never updates the screen properly. PPSSPP goes down to the bottom left corner, and there's a blue background. Windows "behind" this blue background can be interacted with, though since they're effectively invisible, it's impossible to tell what you're interacting with. Reentering fullscreen mode works properly. It's just not restoring the borders properly, and allowing the display to update correctly. I'll try to record a video to demonstrate what I mean. Nevermind, this laptop doesn't support DirectX 10, so I can't record.

Like if you select a new window size?

Has no impact on if it can exit fullscreen or not.

Does going info a game fix it / does it happen while playing or menu only?

No, the only thing going into a game does is make the blue background turn black.

Does changing render resolution affect it?

No.

[thedax]

I don't understand what's going on with Intel GPUs anymore. If I don't use SetMenu(hwnd, NULL) at all, then it exits and enters fullscreen just fine without the pixel format setting nonsense I tried above, at the cost of the menu bar always being visible. :\

[unknownbrackets]

Well, that's interesting.

What if we defer SetMenu? Maybe the problem is the timing. That call probably resizes the client area.

What if you put it after ResizeDisplay and such? Otherwise, maybe a PostMessage() like WM_USER_UPDATE_UI, and have that enforce the menu based on the fullscreen setting. It might cause the menu to close/open a bit late, but it would also stagger the events and possibly fix anything that is confusing the Intel driver.

-[Unknown]

[thedax]

Deferring it in any way makes no difference.

[yetijumpedthetrap]

My phantasy star 2 port. Still runs slow i have gold and would like to
knock w which options to choose
On Jun 25, 2014 12:50 PM, "Unknown W. Brackets" notifications@github.com
wrote:

Well, that's interesting.

What if we defer SetMenu? Maybe the problem is the timing. That will
probably resize the client area.

What if you put it after ResizeDisplay and such? Otherwise, maybe a
PostMessage() like WM_USER_UPDATE_UI, and have that enforce the menu based
on the fullscreen setting. It might cause the menu to close a bit late, but
it would also stagger the events and possibly fix anything that is
confusing the Intel driver.

-[Unknown]

—
Reply to this email directly or view it on GitHub
#6295 (comment).

[unknownbrackets]

What if you make it SetMenu(hwnd, NULL) when you do something else, like toggle vertex cache or something? Does it corrupt the display if you do it at any point after fullscreen/window? Or is it just SetMenu - does it corrupt it if you just hide/show the menu without even going all the way to fullscreen?

-[Unknown]

[yetijumpedthetrap]

Yeah the floor is about half way up my character and cantsee the enemy s or
the item s tillright u close but are still on your plane
On Jun 25, 2014 12:58 PM, "Unknown W. Brackets" notifications@github.com
wrote:

What if you make it SetMenu(hwnd, NULL) when you do something else, like
toggle vertex cache or something? Does it corrupt the display if you do it
at any point after fullscreen/window? Or is it just SetMenu - does it
corrupt it if you just hide/show the menu without even going all the way to
fullscreen?

-[Unknown]

—
Reply to this email directly or view it on GitHub
#6295 (comment).

[thedax]

It only corrupts if I go fullscreen and try to exit (if I just leave it in fullscreen, it works fine). If I keep the menu bar visible in fullscreen until toggling vertex cache for example, then it resizes the display correctly. It's basically the removal of the menu in fullscreen that causes it to never exit properly.

[unknownbrackets]

What if you remove the menu in windowed (vertexcache), then switch to full screen, then switch back, then add the menu back (vertexcache)?

-[Unknown]

[thedax]

The window never reverts properly with your idea. It still just shrinks down to the bottom left.

[unknownbrackets]

Try:

dwStyle &= ~WS_OVERLAPPEDWINDOW;

To:

dwStyle = (dwStyle & ~WS_OVERLAPPEDWINDOW) | WS_POPUP | WS_CLIPCHILDREN | WS_CLIPSIBLINGS | WS_SYSMENU;

Or possibly without WS_SYSMENU? See:

http://stackoverflow.com/questions/7193197/is-there-a-graceful-way-to-handle-toggling-between-fullscreen-and-windowed-mode

Does ChangeDisplaySettings(NULL, 0); work to reset it?

-[Unknown]

[thedax]

None of those flags make any difference. ChangeDisplaySettings(NULL, 0); makes my laptop go to a black screen.

[yetijumpedthetrap]

Thanx player ill try it when i get back home sny other emulators you could
hip me to igot epsxe but this one works like no other
On Jun 25, 2014 1:13 PM, "thedax" notifications@github.com wrote:

It only corrupts if I go fullscreen and try to exit. If I keep the menu
bar visible in fullscreen until toggling vertex cache for example, then it
resizes the display correctly. It's basically the removal of the menu in
fullscreen that causes it to never exit properly.

—
Reply to this email directly or view it on GitHub
#6295 (comment).

[unknownbrackets]

From our discussion previously, it seems like re-asserting the pixel format works around this problem, right? And also, not hiding the menu in full screen. Which is weird.

-[Unknown]

[Metafalica]

I have the same problem as ticket starter.
I think this is Intel HD Graphics issue only, since such problem doesn't exist on Radeon HD 5750.
I tried my best to visually show how it looks like.

[thedax]

From our discussion previously, it seems like re-asserting the pixel format works around this problem, right?

It only worked for exiting fullscreen if PPSSPP was started in it, iirc. It seems like this whole problem is related to showing/hiding the menu for whatever reason.

[hrydgard]

Tried to clean the fullscreen resizing process up a little, not sure if it will help but please try it.

[thedax]

I'll grab my mother's laptop real quick.

[thedax]

Unfortunately, it's the same song and dance with the newest build. @Metafalica's images describe it best.

[ClubIce]

When you try to return to window mode, pres Ctrlt + Alt + Del and open task manager then PPSSPP crash

[hrydgard]

Alright, that does it. I'm reintroducing the inner window hack...

[thedax]

I can't reproduce the crash, but the window does get all weird when I do that. I can freely say I hate Intel GPUs. They're awful.

[hrydgard]

Seems that did it, closing (with sadness) :P

[unknownbrackets]

Clearly, the Intel driver is doing something special for windows that are sized at 0,0 - SM_CXSCREEN,SM_CYSCREEN. If any coordinate is offset by 1, it does not happen.

-[Unknown]

[unknownbrackets]

I wonder if we could use SW_MAXIMIZE instead and win something. At least we might forego the whole remembering the old size thing.

-[Unknown]