Created attachment 162468 [details]
KF5

I think I figured out what's happening here, and it's due to differences in how Qt 5 and Qt 6 detect scale factors.

My monitor has natural scale factor of about 1.2 or 1.25, but I don't use fractional scaling since it doesn't look good with 1.25 scale (in particular SVG icons aren't sharp because it messes with their pixel grid alignment). Instead I keep scaling slider in Plasma settings at 100% and change only font size. Since I use X11 I do it through font dpi setting (it's less work this way) and it works as expected with Qt 5. However Qt 6 seems to derive it's highdpi scale factor from font dpi, and uses it to scale the whole app. Changing font sizes directly and keeping dpi at 96 seems to fix this so there is a workaround.

What all this means, however, is that this borders appears due to fractional scaling. I tested it with QT_SCALE_FACTOR and Qt 5 is affected too.
My main concern right is Windows, where 1.25 scale factor is decided by the OS and I don't think there is a way to apply it to fonts only (and my users won't bother with it anyway). This border is present on Windows with 1.25 scale factor too, and I would like to solve this issue somehow.

I tested with non-fractional QT_SCALE_FACTOR=2 on my lowdpi laptop, and also see the border to the right & bottom with any KTitleWidget with the Fusion style.
This is due to KTitleWidget internally using a QFrame with QFrame::StyledPanel, where the Fusion style seems to actually draws some frame for that type: https://invent.kde.org/qt/qt/qtbase/-/blob/6.7/src/widgets/styles/qfusionstyle.cpp?ref_type=heads#L502
Though at the same time KTitleWidget set the contents margin for that QFrame to zeros, which seems to actually clip any frame lines reaching into the content, in effect with zero margins rendering no frame whatever one has set as frameShape.

Seems that on hidpi scaling some miscalculation happens on that clipping though, and thus on the right and bottom the frame line gets visible again. This part so far a working theory, not yet researched in the code.

In any case there is some related MR currently proposed with https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/251

That one drops that internal QFrame element, and thus indirectly also solves the glitch seen here :)

Though the rendering glitch of QFrame might still be something to file against Qt itself if above working theory yields true by some sample code yet to be written (might write more test code later tonight). So for now just dumping notes about current state here.

Wrote some sample program overlaying the rendering of QFrame, and indeed seems a Fusion style glitch in scaled rendering.
Created https://bugreports.qt.io/browse/QTBUG-126009 where the sample program and some screenshot can be found.

https://invent.kde.org/frameworks/kwidgetsaddons/-/merge_requests/251 can still be considered a work-around effectively (by removing that frame usage), so will link the MR also as bug fix here :)

Git commit cb0f60c54e092a647ccf3831a0bc8ab08d79a3b8 by Friedrich W. H. Kossebau.
Committed on 07/06/2024 at 22:09.
Pushed by kossebau into branch 'master'.

KTitleWidget: do not autoFillBackground by default, drop StyledPanel frame

The use of autoFillBackground is inconsistent in behaviour of a plain
QLabel (which could be considered a sibling widget type), that paints
the text or pixmap simply onto whatever background the container
widget uses.
Both Breeze & Oxygen even have special code to overwrite this.
ba2252ecdb7d099ff49f46c91c8bdd3e08f34a45 before tried to work-around
the visual effects in prominent usages by defaulting to another
backgroundRole (Base -> Window) but that just moved issues to other
usages with other container backgrounds.

The hard-coded use of a StyledPanel frame also is not in balance with
the default QLabel behaviour. With both Breeze & Oxygen both drawing
nothing with StyledPanel, other than other styles, a frame around the
title widget might come as surprise there when implementing the UI with
KTitleWidget.
And since d3964629cbff90f243c7fd43e41ecdf919c4af1b changed
the contents margins to 0, this pushes the official frame rect, which
is calculated to be around the content, also outside the QFrame widget,
and thus clipped on rendering. So no frame should be seen anyway.

The remove of the QFrame also effectively solves a glitch with the
Fusion style in scaled rendering (QTBUG-126009) and thus the need to
work-around it:
FIXED-IN: 6.4.0

M  +4    -15   src/ktitlewidget.cpp

https://invent.kde.org/frameworks/kwidgetsaddons/-/commit/cb0f60c54e092a647ccf3831a0bc8ab08d79a3b8