[MU4 Issue] Transparent app border on Windows
Closed this issue · 19 comments
A transparent frame is visible around the app window and buttons are visually offset so you have to click above and to the left of each button to activate it.
Occurs on Windows in the nightly builds as well as in self-compiled builds.
MuseScore_transparent_border.mp4
Desktop:
- OS: Windows 10, when compiled outside Qt Creator (e.g. Nightly builds, or with the build.cmake script)
System specs: (it's a MacBook Pro running Windows in a dual-boot setup)
Report from a community member:
The transparent frame only appears when I run the Musescore NightlyBuilds via the processor's own Intel graphics, but not via the NVidia graphics card...
Any progress on this? It makes working with MU4 just to test my own changes seriously painful...and I can't figure out what's causing it either, something buried inside Qt itself it seems.
@Eism is working on Windows-titlebar related things (see #8221 (comment)) so I guess he will fix this one too.
@cbjeukendrup
I also hope so :)
How did you build it? My understanding is that it doesn't happen when built with QtCreator. @RomanPudashkin
This is just an ASUS laptop with Intel HD Graphics 530 and NVIDIA GForce GTX as display adapters. I don't know how to run an app using a particular adapter.
How did you build it? My understanding is that it doesn't happen when built with QtCreator
Yes, I have built it using QtCreator
If you build just with MSVC or use the nightly Windows build does it happen?
My QtCreator already uses MSVC
My QtCreator already uses MSVC
Uses it yes, but obviously something in the build process is different. And it's not cmake - I tried building from the command line using Qt's cmake and got the same same problem.
@RomanPudashkin, @Eism, I added information about hardware and setup to the description.
Changing WS_CAPTION to WS_BORDER in WinFramelessWindowController::init fixes the mouse offset problem, but not the transparent frame. Removing WS_THICKFRAME fixes that but it still doesn't render 100% correctly and more importantly is no longer resizable. Leaving that and removing the call to DwmExtendFrameIntoClientArea also works but it's still not quite right (especially when switching back from another application).
Seems to be something we're doing in calculateWindowSize, but nothing I've tried gets the expected result (it seems a bit odd that were adjusting the window rect then passing that back as the client rect). I think there's also an issue with how everything is painted, it looks like everything should be higher by a few pixels.
The best rest I can get is to change WS_CAPTION to WS_BORDER, skip the call to DwmExtendFrameIntoClientArea and don't handle WM_NCCALCSIZE (return false). There's 5 or 6 pixel height white frame at the top but other than that it looks OK.
TBC, I don't intend to put up a PR for this as I don't think it's the right fix, and I don't know what the thinking was behind the original code. Nor do I understand how it could possibly be different when built using QtCreator. But I'm using these changes locally just so I can at least use the version I build.
I've bumped this to P0.
Hearing it come up quite a bit. If people are seeing it in nightlies, than it's a potentially massive problem.
I'd have asumed 0 meaning no priority at all ;-)
I'd have asumed 0 meaning no priority at all ;-)
Yeah... I think P1 is usually the highest... but anyway, we have this system where P0 means 'critical'. So for crashes or anything that makes the app fundamentally unusable.
Incidentally, we are establishing a process where all crashes should be assigned to @vpereverzev, who will assign them to one of our internal dev team. We want to make the app much more stable than it is currently and keep it that way, especially since the majority of features are nearly in and we're nearing the period where we want to start stabilising it.
I've added a screen capture to the description. @Eism's fix didn't work for me or @wizofaus, unfortunately, but the problem does seem to be related to OpenGL. See #8872 (comment).