New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

windows: sometimes missing mpv taskbar item if started in fullscreen #2451

Closed
avih opened this Issue Nov 6, 2015 · 10 comments

Comments

Projects
None yet
7 participants
@avih
Contributor

avih commented Nov 6, 2015

If mpv is executed as mpv --fs myclip and it starts in fullscreen, and then pressing 'f' to exit fullscreen, sometimes there's no mpv item on the taskbar.

This happens both with --vo=opengl and with --vo=direct3d, and with both VOs I've seen it both with a taskbar item and without, so it seems random and unrelated to the vo.

Tested on windows 8.1 64 with mpv 32.

@ChrisK2 ChrisK2 added the ms-windows label Nov 9, 2015

@RosadinTV

This comment has been minimized.

RosadinTV commented Nov 9, 2015

Yes, also it happens to me sometimes.
But if you press Alt+Tab to select MPV, the icon is displayed again.

@avih

This comment has been minimized.

Contributor

avih commented Nov 10, 2015

But if ...

Sure, but it's still a bug.

@rossy

This comment has been minimized.

Member

rossy commented Nov 10, 2015

I can't reproduce this bug on my Windows 8.1 machine, but I wonder if it would help to add WS_EX_APPWINDOW as an extended window style in CreateWindowExW.

@avih

This comment has been minimized.

Contributor

avih commented Nov 10, 2015

As far as I can tell, using the patch below, it still behaves the same (i.e. still random on my system):

--- a/video/out/w32_common.c
+++ b/video/out/w32_common.c
@@ -1161,19 +1161,19 @@ static void *gui_thread(void *ptr)
     if (w32->parent) {
         RECT r;
         GetClientRect(w32->parent, &r);
         w32->window = CreateWindowExW(WS_EX_NOPARENTNOTIFY, classname,
                                       classname,
                                       WS_CHILD | WS_VISIBLE,
                                       0, 0, r.right, r.bottom,
                                       w32->parent, 0, hInstance, NULL);
     } else {
-        w32->window = CreateWindowExW(0, classname,
+        w32->window = CreateWindowExW(WS_EX_APPWINDOW, classname,
                                       classname,
                                       update_style(w32, 0),
                                       CW_USEDEFAULT, SW_HIDE, 100, 100,
                                       0, 0, hInstance, NULL);
     }
@avih

This comment has been minimized.

Contributor

avih commented Nov 10, 2015

I just also tested with d3d. The above (still random the same) is still true for OpenGL output, but with d3d output is seems to be mostly OK. In about 20 attempts, the taskbar item didn't show only on one case, and before the patch it's roughly 50-50 if the bug happens or not.

@lachs0r

This comment has been minimized.

Member

lachs0r commented Nov 13, 2015

I guess this also happens due to Windows’ exclusive fullscreen window heuristics.
Try this build: http://tmp.srsfckn.biz/mpv_ws.exe.xz

@lachs0r

This comment has been minimized.

Member

lachs0r commented Nov 13, 2015

Actually this also depends on the window style flags, and there can be random delays before windows decides whether or not to show a taskbar entry. We’ll have to ask Raymond Chen about how exactly this works, but I suspect WS_POPUP can prevent the window from getting a taskbar entry if it is set early enough. If that is true, the build I just posted should also work around this, since it no longer uses that style (it removes all style flags though, so not sure how Windows will react).

If this does not help either, we can try again with WS_EX_APPWINDOW, and if that still does not reliably fix the problem, we can try creating a window, showing it, and only switching to fullscreen mode once it is on screen.

@rossy

This comment has been minimized.

Member

rossy commented Nov 13, 2015

Well, this fixes the other exclusive fullscreen problem (tearing) on my PC, so it looks good.

(it removes all style flags though, so not sure how Windows will react).

Setting window styles to 0 is the same as WS_OVERLAPPED (#define WS_OVERLAPPED 0x00000000L,) so it's totally well defined.

@avih

This comment has been minimized.

Contributor

avih commented Nov 13, 2015

I guess this also happens due to Windows’ exclusive fullscreen window heuristics.
Try this build: http://tmp.srsfckn.biz/mpv_ws.exe.xz

So what patch did you use here?

It doesn't fix it for me.

(Also, personally I don't care much about this bug. A user on IRC asked me to reproduce so I did, and then filed it for him).

@rossy rossy closed this in #3894 Dec 12, 2016

rossy added a commit that referenced this issue Dec 12, 2016

win32: window styles improvements
Allow minimizing the borderless/fullscreen window by clicking on the
taskbar button or pressing Win+Down hotkey.

Also fixes #2229 and probably fixes #2451
@pavelxdd

This comment has been minimized.

Contributor

pavelxdd commented Dec 16, 2016

This issue is always reproducible for me on Windows 8, so it probably should be reopened.

I think, the only way to solve this, as @lachs0r said, would be:

we can try creating a window, showing it, and only switching to fullscreen mode once it is on screen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment