Windows11 style issues

Hello,
Thanks for the update, but I've noticed a few new bugs:

In QMPlay2 26.06.27, when using the 'windows11' style, the active line in the playlist is highlighted using the highlight color. However, the highlighted text color seems to be ignored, and the text always remains black on a light OS theme.
In full screen mode, a border is occasionally visible at the edges of the screen when using the 'windows11' style.
Right-clicking to open the context menu during video playback triggers a warning: QWidgetWindow(name="videoDockWindow") must be a top level window.

Could you please check these issues?
Thank you.

I didn't notice Issue 2, because it's not a problem on VM (no GPU drivers), but it should be reported here: https://qt-project.atlassian.net/ - looks like Qt it adding stupid ugly border everywhere breaking full screen mode. Windows 11 style is always bugged in Qt, in each Qt version something is not looking correctly.

Issue 1 seems to be a Qt bug, too, but I'll check it.

Issue 3 - also Qt, not important, can be silenced.

Issue 2 seems to be qt/qtbase@c3f953b

I can't see any way of fixing it. The only workaround could be the event filter for QEvent::Show, but potentially it can break other things in style.

It seems that Qt added some "feature" without testing it e.g. in full screen.

I'll revert some patches or downgrade Qt, thanks for the info.

https://qt-project.atlassian.net/browse/QTBUG-147453

https://qt-project.atlassian.net/browse/QTBUG-147453

Yes, that's it. I took a FHD screenshot with a white desktop background:

This border is transparent and less noticeable with dark wallpaper.

I'll revert some patches or downgrade Qt, thanks for the info.

Okay, thank you!

Can I use your screenshot for qt bugreport?

Yes, of course. I replaced the screenshot with a new one where the taskbar is hidden to make the border more visible.

Could you check if this qt/qtbase@f0e51b9 can fix isssue 1?

Could you check if this qt/qtbase@f0e51b9 can fix isssue 1?

I don't have a Qt development environment set up on Windows right now. However, if you can provide a pre-built Qt binary with these changes, I can test it 🙂

What exactly happens with issue 1?

Released v2, issues should be fixed (one patch has been backported, another is strict condition when rounded border should be applied and one is fixing alternating colors for dark mode fustion style (same as previous QMPlay2 release)!

What exactly happens with issue 1?

The Highlighted text color from the QMPlay2 Set appearance settings is not being applied. As a result, the text on the active playlist row is hard to read when using a light OS theme with a specific wallpaper (e.g. a black one).

Released v2, issues should be fixed (one patch has been backported, another is strict condition when rounded border should be applied and one is fixing alternating colors for dark mode fustion style (same as previous QMPlay2 release)!

Yes, everything is working fine now (all highlight colors from the QMPlay2 Set appearance settings are being ignored). Thank you!

@zaps166

Hello @zaps166,
While investigating the full screen border issue on Windows, I noticed that for Vulkan, the border remained visible even when bypass compositor in full screen was enabled. Does this mean the compositor isn't being bypassed properly?

Additionally, when playback controls (the bottom panel) are active in Vulkan, the video stretches slightly to the right. In OpenGL, the border only appeared when this panel was visible in full screen mode.

The border issue has been fixed in QMPlay2-Win64-26.06.27-v2 (the border was only visible with the 'windows11' style). However, this revealed that something was wrong with compositor bypassing in Vulkan. I can't test this on AMD, but it doesn't seem to work for me on NVIDIA at the moment, and the code at InDockW.cpp#L124-L131 isn't executing correctly for Vulkan.

However, this revealed that something was wrong with compositor bypassing in Vulkan. I can't test this on AMD, but it doesn't seem to work for me on NVIDIA at the moment, and the code at InDockW.cpp#L124-L131 isn't executing correctly for Vulkan.

is it regression - does it happen with 25.09.11?
does it happen on Fusion style?

Yes, it happens on AMD, too, but I didn't check anything else about it yet, so I'm asking.

It also affects 25.09.11 across all styles.

I see. I have to run real windows and look at this. But maybe the video driver is using the border to prevent full screen optimization? How about border in OpenGL?

The video stretching bug is fixed for Vulkan, but the bottom panel breaks for OpenGL. This is also likely an indication that the compositor bypass isn't working in Vulkan...
What do you think?

I don't remember, need to check it. It's just a workaround to not cover exactly entire screen, so Window will not apply full screen optimization.

How about border in OpenGL?

Additionally, when playback controls (the bottom panel) are active in Vulkan, the video stretches slightly to the right. In OpenGL, the border only appeared when this panel was visible in full screen mode.

I re-checked on Windows 11 and AMD, 2 computers (QMPlay2 v2 release):

no borders with full screen bypass enabled in OpenGL and Vulkan
no borders with full screen bypass disabled in OpenGL and Vulkan
no video stretching in OpenGL and Vulkan in any fullscreen mode

On older hardware - flickering when full screen optimization is toggled due to panels visibility (optimization is visible as notable reduction of GPU usage).

On newer hardware - no flickering (only little stuttering) when panels visibility is toggled - didn't check if optimization is really working correctly on this hardware.

Other broken things on Windows which work on Linux Mesa drivers (VkVideo):

I don't have access to Windows 11 with Nvidia hardware, so can't test it.

Thanks for checking on other GPUs. On NVIDIA, with full screen bypass enabled in Vulkan, I observe the following:

I used this test video: https://www.youtube.com/watch?v=YyZq_lEJZ2U. Is it possible that this is a driver bug? Is there a more reliable way to check for bypass other than w->property("bypassCompositor").toInt()?

Stretching ~1px is because of moving internal window with GPU content to prevent full screen optimization when panel or popup menu is displayed (otherwise panels could be invisible, but clickable). This was the fastest way to do it on Windows.

I thought you have completely glitched video, but it's just 1px.

It depends on the video (sometimes it is very noticeable), but this never happens in OpenGL. I also don't see this on Intel in Vulkan (probably the bypass works there, since there is flickering).

but this never happens in OpenGL

If you have bypass enabled for OpenGL, it should be the same as in Vulkan. Otherwise, if you turn off compositor bypass, it never happens, because whole video is displayed with tiny stretch (correct me if I'm wrong).

I also don't see this on Intel in Vulkan (probably the bypass works there, since there is flickering).

In Vulkan it partially depends on VK_EXT_full_screen_exclusive. If bypass is enabled, it should work similar to OpenGL, but if bypass in disabled - don't remember, but IIRC it uses VK_EXT_full_screen_exclusive if possible.

Bypass is enabled for all my tests, however I don't see stretching in OpenGL, but I do see flickering when the bottom panel appears (just like on Intel in Vulkan) 🤔

What do you think?

AI analysis (skimmed, mostly correct)

Bypass Compositor for Full Screen in QMPlay2

Settings and Default Values

Parameter	Key	Default
OpenGL	`OpenGL/BypassCompositor`	false
Vulkan	`Vulkan/BypassCompositor`	true

Windows Mechanism

OpenGL

Sets the Qt property bypassCompositor on the widget as an int: 1 (bypass) or -1 (no bypass). The value -1 (not 0) is important — InDockW distinguishes between both states.

When the setting is toggled, doReset = true is set, causing a full surface repaint.

Exception: Windows 7/Vista — checks DwmIsCompositionEnabled(). If DWM is already disabled, bypass is forced regardless of the setting.

Vulkan

Sets the bypassCompositor property as a bool (true/false), then calls resetSwapChainAndGraphicsPipelines() — recreating the swap chain and pipelines.

VK_EXT_full_screen_exclusive (Vulkan, Windows)

The extension is registered as optional in the physicalDeviceExtensions list (VulkanInstance.cpp:513). It is not required — if the driver supports it, it will be activated.

When creating the swap chain (SwapChain.cpp:82-85), exclusive full screen is active only when both conditions are met:

exclusiveFullScreen = (bypassCompositor == true)
                   && (device supports VK_EXT_full_screen_exclusive)

eAllowed → chained into pNext via vk::SurfaceFullScreenExclusiveInfoEXT, forces imageCount = 2
eDisallowed → swap chain works normally without exclusive fullscreen

If the device does not support the extension, exclusiveFullScreen = false and pNext is not chained, regardless of the bypassCompositor state.

During device enumeration, the bypass checkbox is disabled in the UI for devices that lack extension support.

Context Menu / Panels (InDockW)

In InDockW::resizeEvent (Windows):

const int bypassCompositor = w->property("bypassCompositor").toInt();
if ((bypassCompositor == -1 ||
     (bypassCompositor == 1 && (loseHeight > 0 || QApplication::activePopupWidget())))
    && window()->property("fullScreen").toBool())
{
    X -= 1;
    W += 2;
}

The video widget is extended by 2 pixels (1 on each side) to cover visible seams between the render surface and the edges of panels/context menus appearing during fullscreen playback.

OpenGL RTT (-1): workaround always active in fullscreen
OpenGL without RTT (1): workaround active only when a panel loses height or a popup is visible
Vulkan (true/false): toInt() yields 0, so workaround active only when a popup is visible

X11 Mechanism (Shared Between OpenGL and Vulkan)

Both renderers inherit from X11BypassCompositor. It sets the _NET_WM_BYPASS_COMPOSITOR X11 window property: 1 = bypass, 0 = restore compositor. The state is tracked via the fullScreenChanged signal — bypass is active only in fullscreen.

Bypass is enabled for all my tests, however I don't see stretching in OpenGL, but I do see flickering when the bottom panel appears (just like on Intel in Vulkan) 🤔

Flickering is a common problem with driver and windows. Maybe only DirectX 12 can do it better on Windows. Unlike X11 and Wayland, on Windows toggling full screen optimizations (exclusive full screen, direct scanout - whatever it's called) is much worse. But this improves performance and frame timing, especially for slow GPUs and/or running on battery.

I don't know why you can't see stretching in OpenGL - does it enter the:

            X -= 1;
            W += 2;

? If yes, it also stretches, but maybe it's hard to notice or driver is doing other magic.

Okay, thanks for the analysis, I hope it helps improve something 😅

It's just strange that Vulkan behaves differently (stretching on NVIDIA and flickering on Intel) if everything works correctly. It seems the bypass doesn't work for me in Vulkan on NVIDIA, and the driver doesn't apply its 'magic'. However, QMPlay2 assumes the bypass is successful and stretches the video when the bottom panel is visible.

Navigation Menu

Repository navigation

Windows11 style issues #1019

2 remaining items

Bypass Compositor for Full Screen in QMPlay2

Settings and Default Values

Windows Mechanism

OpenGL

Vulkan

VK_EXT_full_screen_exclusive (Vulkan, Windows)

Context Menu / Panels (InDockW)

X11 Mechanism (Shared Between OpenGL and Vulkan)

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Windows11 style issues #1019

Description

Activity

zaps166 commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

Realex-fire commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

Realex-fire commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

Realex-fire commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

zaps166 commented on Jun 28, 2026

Realex-fire commented on Jun 28, 2026

Realex-fire commented on Jun 29, 2026

2 remaining items

Realex-fire commented on Jul 3, 2026

zaps166 commented on Jul 3, 2026

Realex-fire commented on Jul 4, 2026

zaps166 commented on Jul 4, 2026

Realex-fire commented on Jul 4, 2026

zaps166 commented on Jul 5, 2026

zaps166 commented on Jul 5, 2026

Realex-fire commented on Jul 5, 2026

zaps166 commented on Jul 5, 2026

Realex-fire commented on Jul 5, 2026

zaps166 commented on Jul 5, 2026

Realex-fire commented on Jul 5, 2026

zaps166 commented on Jul 5, 2026

Bypass Compositor for Full Screen in QMPlay2

Settings and Default Values

Windows Mechanism

OpenGL

Vulkan

VK_EXT_full_screen_exclusive (Vulkan, Windows)

Context Menu / Panels (InDockW)

X11 Mechanism (Shared Between OpenGL and Vulkan)

zaps166 commented on Jul 5, 2026

Realex-fire commented on Jul 5, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions