https://bugs.kde.org/show_bug.cgi?id=487521
--- Comment #4 from Friedrich W. H. Kossebau <[email protected]> --- Hi. As first remark, Jason, please do not subscribe people to bug reports, unless they might have caused a bug perhaps. In this case, given you caught my curiousity still initially, I had a look at the actual code. Fear the proposed changes do not make sense to me. Instead I wonder why qApp->devicePixelRatio() is brought into the calculcation at all, any values involved should be actually based on logical pixel sizes, not physical ones (even though I would think the API docs of QWheelEvent::pixelDelta() are a tad unclear themselves)? Also, qApp->devicePixelRatio() also would be "the highest screen device pixel ratio found on the system" not the one where the current widget is on (see https://doc.qt.io/qt-6/qguiapplication.html#devicePixelRatio). So in general, unrelated to the bug report here, I propose to fix that logic to remove the questionable scaling and just as elsewhere use plain fontHeight for the scroll-step-effective height. About the actual bug report, the experienced slow scrolling on wayland, I wonder if this might not be due to different lower level input handling of the wheel events, of X11 vs. Wayland. Myself just switched to wayland for Plasma 6.8, and scrolling in Firefox also seems "slower". Also compare this info in the docs on QWheelEvent::pixelDelta(), the value used in the calculation to estimate the pixels to scroll along: > Note: On X11 this value is driver-specific and unreliable, use angleDelta() > instead. Asking a search engine about scrolling and wayland, seems input handling is a general challenge still. No own idea what to do here. Going to create a MR now to remove the devicePixelRation scaling now, as that seems wrong in any case to me. -- You are receiving this mail because: You are watching all bug changes.
