SUMMARY I'm using 1.5 scale factor for my monitor with 2560x1440 resolution. On wayland session it is all blurry, including xwayland. But I've noticed when I used my laptop with 3200x1800 resolution and 2.5 scale it is crystal fine. > 2560/1.5 1706.6666666666667 > 3200/2.5 1280 So it seems some rounding issues is here. On KDE5 kwin branch it is totally fine with that, something broken in master branch. X11 session is working well with KDE6 branch. STEPS TO REPRODUCE 1. Login in to the wayland session 2. Choice scale that can't be divided into integer result 3. All has been blurred OBSERVED RESULT Blurred screen EXPECTED RESULT Crystal clear screen SOFTWARE/OS VERSIONS KDE NEON with KDE6 installed and updated to Sat Oct 7 06:43:50 PM EEST 2023
I also can confirm this on Plasma 6 Alpha. I am on 3840x2160 resolution but for me the 1.5 scale does not blurry as 3280/1.5 = 2560, all other scales that cannot divide the resolution to integer resulting blurry fonts.
kwin have a nice feature to highlight surfaces that doesn't fit to dest size: KWIN_SCENE_VISUALIZE=fractional kwin_wayland ...
Created attachment 163293 [details] An insufficient fix/workaround for the bug, only fix the blurriness of QT apps After some digging on kwin and fractional debug shader pass [1], I have found there are mismatches between renderTarget.size() and deivce geometry calculated using viewport.renderRect() * viewport.scale() that cause the unalignment of items. Fix it by supplying `fractionalGeometry()` of output instead of `geometry()` into RenderViewport in WorkspaceScene. However this fix/workaround is insufficient and does not fix the blurriness of decoration title[2] and some non-QT apps like Firefox, Electron and VS Code with fractional-scale-v1 integration enabled on fractional logical geometry. Surprisingly, the QPainter backend(KWIN_COMPOSE=Q) has no problem on all of these case at all (without the mentioned patch of course), all components looks sharp under any scales no matter it's QT6 apps or other fractional-scale-v1apps. So there is certainly some other alignment issues in OpenGL backend. [1] https://invent.kde.org/plasma/kwin/-/merge_requests/3988 [2] https://bugs.kde.org/show_bug.cgi?id=475886
(In reply to Huang-Huang Bao from comment #3) > Created attachment 163293 [details] > An insufficient fix/workaround for the bug, only fix the blurriness of QT > apps Sorry, it fixes the blurriness of workspace scene, QT6 app itself is all fine with fractional scale.
Created attachment 163295 [details] KWIN_SCENE_VISUALIZE=fractional without the patch Notice the very left column in workspace scene is not colored because the fractional error is under 0.01.
Created attachment 163296 [details] KWIN_SCENE_VISUALIZE=fractional with "An insufficient fix/workaround for the bug" patch applied Firefox and VS Code both have fractional-scale integration enabled but are still blurry in 3840x2160 / 1.8 scale.
Chromium-based apps have incomplete fractional scale support. They calculate scale factor instead of obtaining one from the fractional-scale protocol. See: https://bugs.chromium.org/p/chromium/issues/detail?id=1474176 I think firefox also doing something wrong.
Huang-Huang Bao, I think your patch makes sense. Please create a MR: https://invent.kde.org/plasma/kwin It seems it was typo when they refactor this(and this is why kwin5 branch is fine): void WorkspaceScene::prePaint(SceneDelegate *delegate) { createStackingOrder(); m_paintedDelegate = delegate; if (kwinApp()->operationMode() == Application::OperationModeX11) { painted_screen = workspace()->outputs().constFirst(); m_renderer->setRenderTargetRect(geometry()); m_renderer->setRenderTargetScale(1); } else { painted_screen = m_paintedDelegate->output(); m_renderer->setRenderTargetRect(painted_screen->fractionalGeometry()); m_renderer->setRenderTargetScale(painted_screen->scale()); }
(In reply to zvova7890 from comment #7) > Chromium-based apps have incomplete fractional scale support. They calculate > scale factor instead of obtaining one from the fractional-scale protocol. > See: https://bugs.chromium.org/p/chromium/issues/detail?id=1474176 > > I think firefox also doing something wrong. The fractional-scale-v1 spec does not force the client to use provided scale as the event name "wp_fractional_scale_v1::preferred_scale" suggests. > Notification of a new preferred scale for this surface that the compositor suggests that the client should use. So I would say it's a bug of the kwin's OpenGL backend to not respect client's scale (client's buffer geometry / surface geometry).. And the QPainter backend seems doing it fine.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/4665
Well, yes, but Chrome's 1.49971 scale factor does not seem to be a 'normal' scale when the system has 1.5 While Chrome has an incorrect scale, I believe it is providing an incorrect viewporter destination size, while KWin is trying to render with the correct size applying a 1.5 scale. From that perspective, the compositor must fit the application surface to the render bounds. The OpenGL backend uses GL_LINEAR texture filtering, which causes blurriness even with rounding issues within 1px. Maybe QPainter applies another scale method. I have a patch for Chromium that fixes its internal scale, and in that case, it becomes sharp and clean. Anyway, it's just my guess. I haven't delved deeply into how it works to the point where I can confidently say I totally understand how it must work.
Git commit 3d4036210d85d59836d5f0471a95e863e0b728c4 by Huang-Huang Bao. Committed on 19/11/2023 at 23:14. Pushed by zamundaaa into branch 'master'. scene: use fractionalGeometry() as input of RenderViewport renderRect Fixes mismatches between renderTarget.size() and deivce geometry calculated using viewport.renderRect() * viewport.scale() . M +1 -1 src/scene/workspacescene.cpp https://invent.kde.org/plasma/kwin/-/commit/3d4036210d85d59836d5f0471a95e863e0b728c4