Fullscreen borderless window with 'owned' window on-top

Question

I have two OpenGL windows: a main one and a smaller one that is set to be 'owned' by the main one (hWndParent is set in CreateWindowEx, but the WS_CHILD style is not set). If I then convert my main window to be borderless and the same size as my desktop it will jump in front of the smaller window even though it's owned and that should not be possible (https://msdn.microsoft.com/en-us/library/windows/desktop/ms632599%28v=vs.85%29.aspx#owned_windows). This is true even if the smaller window is set to be always-on-top.

On it's own this isn't terrible, but the core issue is that I can still click-through my main window on where the smaller window is, and the smaller window will pop infront. I can go between the two windows endlessly like this by clicking on the main window, then clicking-through the main window.

If I make the main window size 1 pixel less than the full desktop size, none of these issues occur and the windows behave is as expected.

I can't find any documentation that describes this behavior. It is a feature to keep windows from going infront of content (such as a video playing back) that isn't documented, or am I just missing it?

I'll mention I'm not using layered or transparent window here, so I don't think click-through should even be possible?

Thanks

Not sure whether OpenGL plays a part, but in general you can stop a window coming to the front on mouse click by returning MA_NOACTIVATE to the WM_MOUSEACTIVATE message. — Jonathan Potter
Thanks for the answer. Unfortunately the issue is bigger than that since the smaller window is taking all of the mouse events as if it was already infront of the main window (mouse over, clicks etc.). So interacting with the main window is busted in this state. — mb13
Another thing you can try is handling WM_NCHITTEST and return HTTRANSPARENT. Without more information / code on your program it's hard to be more specific. — Jonathan Potter
Does this work if you don't have an OpenGL context? Try creating just a regular old window with a button, make it fullscreen, and then open a dialog over it. — andlabs

datenwolf datenwolf · Accepted Answer · 2015-12-19T11:48:11

What you experience may very well be a OpenGL implementation bug that's triggered by the heuristic in which the driver switched between "windowed" and "fullscreen" rendering: You see, for OpenGL there's no special "exclusive fullscreen mode" as Direct3D has. Instead a borderless window covering the whole screen, which is not overlapped by foreign windows may trigger a "fullscreen" detection, which may the OpenGL implementation in question make switch to another code path (namely one, where all pixel ownership tests are disabled and the framebuffer flips go directly to the display scanout, bypassing the windowing compositor.

What you do there is so uncommon, that it likely may have slipped through all conformance tests. Having child windows to a OpenGL window is uncommon in the first place and them being floating is even rarer.

If you've got a minimal example showcase, you should probably report it as a bug to the driver vendor. In the meantime I propose a workaround: Make your OpenGL window a child-window to your top level window (will of course require resizing in the toplevel WM_SIZE) and make your floating window another child to the toplevel; the z-order between childs in a parent window is respected and kept. Being a child to a toplevel window should inhibit most heuristics and OpenGL drivers should not loop at the border and size of OpenGL parent windows.

Fullscreen borderless window with 'owned' window on-top

1 Answers