Created attachment 111457 [details] Shot showing the issue. When display scale != 1 is set, some windows do not fill the entire screen. Small transparent lines appear on the border of the screen, like the window was not sufficiently large to fill the entire screen. I'm attaching an image that shows what I'm describing: I created a sample fullscreen window in QML, entirely filled with orange color. Then I bring konsole to front. On the bottom of the image there is a orange line of height equal to 1 pixel exactly. That means konsole is not large enough and the window below shines through, like there was a wrong approximation during scaling. On the left instead, there is a vertical line, of width 1 pixel, of white color. In that case the orange window below is not visible because the orange window itself was not large enough to fill. Same happens with many other windows, including other KDE apps, VLC player or even when showing the youtube player in fullscreen with chrome.
Is this on X11 or Wayland?
This is X11 sorry. Screen is 4k, glxinfo reports: Extended renderer info (GLX_MESA_query_renderer): Vendor: Intel Open Source Technology Center (0x8086) Device: Mesa DRI Intel(R) HD Graphics P630 (Kaby Lake GT2) (0x591d) Version: 17.2.8 Accelerated: yes Video memory: 3072MB Unified memory: yes Preferred profile: core (0x1) Max core profile version: 4.5 Max compat profile version: 3.0 Max GLES1 profile version: 1.1 Max GLES[23] profile version: 3.2
Can you please provide the output of xprop and xwininfo on a window which is too small? Please also provide the output of qdbus org.kde.KWin /KWin supportInformation I assume this is a bug in Qt. KWin itself ignores any scaling information on X11.
Created attachment 111462 [details] Output of xprop, wwininfo and qdbus.
May explain why chrome and libreoffice, for instance, are properly sized?
How exactly did you set the display scale? Through the kscreen configuration module or through some X11 configuration?
I set it through kscreen, from the plasma settings application.
I think I understand the problem. The decoration has a height of 65 pixels which gives an odd number of pixels for the application. So scaling breaks. But I need to ask experts: @David, does that make sense?
Definitely plausible. I'll take it from here.
*** Bug 399280 has been marked as a duplicate of this bug. ***
Any updates on this one?
Oh, this. Confirmed on X11, not an issue on Wayland. I'll dupe the other reports we have about it to this bug report.
*** Bug 428895 has been marked as a duplicate of this bug. ***
*** Bug 413392 has been marked as a duplicate of this bug. ***
*** Bug 439428 has been marked as a duplicate of this bug. ***
*** Bug 445964 has been marked as a duplicate of this bug. ***
While the issue is present with the Breeze and Plastik themes, the Oxygen window decorations step around it somehow, I've tested with multiple apps and it just works.
*** Bug 449015 has been marked as a duplicate of this bug. ***
*** Bug 423936 has been marked as a duplicate of this bug. ***
Created attachment 147078 [details] screenshot representing the bug I have the same problem on Breeze theme only, X11, Plasma 5.24.2, 200% scaling and 168 DPI fonts (or 175% scaling).
*** Bug 452354 has been marked as a duplicate of this bug. ***
*** Bug 452687 has been marked as a duplicate of this bug. ***
*** Bug 435674 has been marked as a duplicate of this bug. ***
*** Bug 445741 has been marked as a duplicate of this bug. ***
I did some debugging on https://bugs.kde.org/show_bug.cgi?id=445741, which might be relevant here. But I don't know much about kwin, so it's only wild guesses: In X11, kwin seems to force window size to be rounded to the "resize increment" in WM_SIZE_HINTS, in various places. The code is in X11Window::constrainClientSize: https://invent.kde.org/plasma/kwin/-/blob/68f6734d5cf758004c3328777dbf66fe9113b4d6/src/x11window.cpp#L3551 > int width_inc = m_geometryHints.resizeIncrements().width(); > int height_inc = m_geometryHints.resizeIncrements().height(); > int basew_inc = m_geometryHints.baseSize().width(); > int baseh_inc = m_geometryHints.baseSize().height(); > if (!m_geometryHints.hasBaseSize()) { > basew_inc = m_geometryHints.minSize().width(); > baseh_inc = m_geometryHints.minSize().height(); > } > w = int((w - basew_inc) / width_inc) * width_inc + basew_inc; > h = int((h - baseh_inc) / height_inc) * height_inc + baseh_inc; In my laptop, the screen size is 3200x2000, KDE's global scaling set to 250%. Then all KDE apps have "resize increment"=3 in WM_SIZE_HINTS, where all Gnome apps seem to have "resize increment"=2, and other apps (e.g. vscode) don't have it at all. This causes the "fullscreen" window menu in all KDE apps grayed out, because of this check in X11Window::isFullScreenable: https://invent.kde.org/plasma/kwin/-/blob/68f6734d5cf758004c3328777dbf66fe9113b4d6/src/x11window.cpp#L1284 > if (rules()->checkStrictGeometry(true)) { > // check geometry constraints (rule to obey is set) > const QRect fullScreenArea = workspace()->clientArea(FullScreenArea, this); > const QSize constrainedClientSize = constrainClientSize(fullScreenArea.size()); > if (rules()->checkSize(constrainedClientSize) != fullScreenArea.size()) { > return false; // the app wouldn't fit exactly fullscreen geometry due to its strict geometry requirements > } > } Since my screen resolution is not multiple of 3, KDE apps are not allowed to fullscreen. And for this bug, in my laptop, all KDE apps, when launched maximized, the window won't cover the top-right pixel. Clicking on that pixel closes the window behind. However, if I restore that window then maximize again, it works OK. My guess is X11Window::manage also calls X11Window::constrainClientSize: https://invent.kde.org/plasma/kwin/-/blob/68f6734d5cf758004c3328777dbf66fe9113b4d6/src/x11window.cpp#L694 So if the desktop area (fullscreen excluding panel) is not multiple of 3, KDE apps won't exactly cover the whole desktop area when launched maximized. In my case, both problems can be worked around by creating a window rule: "for all windows, force disable Strict Geometry", which bypasses constrainClientSize. This also explains why Wayland doesn't have these problems, because it uses the generic Window::constrainClientSize, which doesn't do rounding at all. Hope this helps.
Thanks for the thorough investigation! Raising priority given the number of duplicates.
BTW, I don't know whether that "resize increment" of 3 or 2 in window hint is set by Qt/GTK or kwin. But neither 3 or 2 doesn't make much sense with 2.5x zoom. If the intent of "resize increment" is to make the client area match the toolkit's layout grid, then for 2.5x zoom it should be 5 really...
>BTW, I don't know whether that "resize increment" of 3 or 2 in window hint is set by Qt/GTK or kwin Resize increments go up with the scale factor from the Qt side. As you say it makes sense for integers to make sure it's always a valid value but for fractional scaling it's just making it worse than if it had stuck with 1.
Upstream: https://bugreports.qt.io/browse/QTBUG-105128 GTK doesn't have fractional scaling so can I assume that's correct?
(In reply to David Edmundson from comment #28) > >BTW, I don't know whether that "resize increment" of 3 or 2 in window hint is set by Qt/GTK or kwin > > Resize increments go up with the scale factor from the Qt side. > > As you say it makes sense for integers to make sure it's always a valid > value but for fractional scaling it's just making it worse than if it had > stuck with 1. Indeed. However, there's still problem for integer scaling. For example, on my laptop with a 3200x2000 screen, when set to 3x zoom, KDE apps still have "Fullscreen" window menu disabled. And when lauched maximized, the window won't cover the top-right pixel. What's worse, this behavior is inconsistent in kwin: when restored then maximized again, that window now covers the the top-right pixel. This is the reason why clicking on the top right corner sometimes closes the window behind. This is unlikely to happen with 2x zoom, since most screen sizes are multiple of 2. But few are multiple of 3 (1920x1080 being the exception). Is it possible that kwin_x11 simply ignores the resize increments hint? Since both GTK and QT apps seem work quite well in kwin_wayland, which seems having no idea of resize increments, so perhaps these toolkits don't really need this hint. (Maybe some terminal emulators do, but xterm works ok) Or at least, could kwin_x11 ignore the resize increments hint for maximized windows?
(In reply to David Edmundson from comment #29) > Upstream: https://bugreports.qt.io/browse/QTBUG-105128 > GTK doesn't have fractional scaling so can I assume that's correct? Yes, mine has GDK_SCALE=2 and GDK_DPI_SCALE=0.5, presumably also set by KDE? However, with GTK in 2x and QT in 2.5x, the buttons and text seem to be the same size in both toolkits. Seems like magic...
> Seems like magic... FontDPI is mostly independent
We'll continue this in Qt
(In reply to David Edmundson from comment #33) > We'll continue this in Qt Beside the fractional scaling cases, this problem is still likely to happen with 3x scaling and a screen/desktop area size not multiple of 3. Is this by design?