Created attachment 171185 [details] Demonstration of sampling relying on cursor position SUMMARY The magnifier that shows when holding shift isn't properly scaled with the resolution of the display, leading to a different result depending on which pixel you're hovering, pretty much defeating the purpose of having it STEPS TO REPRODUCE 1. Start a rectangular image capture 2. Hold shift 3. Move the cursor around OBSERVED RESULT (See attachment) The display is sampled differently in the magnifier depending on where the cursor is EXPECTED RESULT The magnifier should scale properly with the pixels of the display (I believe this is called integer scaling) SOFTWARE/OS VERSIONS Arch Linux 6.9.6-zen KDE Plasma Version: 6.1 KDE Frameworks Version: 6.3 Qt Version: 6.7.2
Can you post a screenshot of your Display Configuration settings?
Created attachment 171188 [details] display configuration settings I'm not familiar with this system, hopefully this works
Note, disabling (but not disconnecting) my second monitor does not change the behavior
(In reply to cooldood909 from comment #2) > Created attachment 171188 [details] > display configuration settings > > I'm not familiar with this system, hopefully this works Actually, what I really wanted was a picture of the screens layout just above the part you shared. The reason why is that it lets me know what your screen arrangement is, how many screens you have, what their resolutions are and what their scales are all in one picture. I can see that you have multiple screens from the presence of the combo box at the top, but the picture only shows the info for Sceptre Tech Inc Sceptre O35.
Created attachment 171189 [details] again Ah, ok, here's the full one
It seems that you don't use fractional scaling or any scaling besides 100%, so I suppose we can rule out fractional scaling being the issue. The magnifier actually magnifies by 3x, so in theory there should be no problem, but that is clearly not the case. I've reproduced the bug on my own system with all screens set to 100% scale. Curiously, the bug only happens in an obvious way when I'm moving the cursor with my touchpad. The touchpad has a higher resolution for detecting movement than my Logitech MX Master 3 mouse does. It seems that in the past, mouse movement was provided in a more predictable way that mapped more closely to how you actually see the cursor move. I measured the mouse positions for movement on my touchpad and mouse and it turns out that mouse positions can now have weird fractional values like (871.352,402.797). The touchpad and mouse both have this issue, but it's much worse with the touchpad. Perhaps this is some kind of Qt or KWin bug? If it's new intentional behavior, I suppose we'll have to manually adjust the mouse positions we receive to prevent the issue this bug is reporting.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/spectacle/-/merge_requests/400
Git commit 380303d4d096e0c7b206c5e55a22574ea2212fe1 by Noah Davis. Committed on 17/09/2024 at 18:52. Pushed by ndavis into branch 'master'. Round mouse positions to physical pixels At some point in the development of Plasma 6.0, mouse positions were changed to be fractional even on 1x scale screens. This is fine in some cases and not necessarily wrong, but it's bad for Spectacle since selection rectangles need to be snapped to physical pixels to make accurate selections. M +5 -0 src/Geometry.cpp M +6 -0 src/Geometry.h M +8 -6 src/Gui/Annotations/AnnotationViewport.cpp M +4 -2 src/Gui/Annotations/CropTool.qml M +2 -2 src/Gui/Annotations/SelectionTool.qml M +2 -2 src/Gui/Annotations/TextTool.qml M +6 -3 src/Gui/SelectionEditor.cpp M +5 -0 src/Gui/SpectacleWindow.cpp M +2 -1 src/Gui/SpectacleWindow.h https://invent.kde.org/graphics/spectacle/-/commit/380303d4d096e0c7b206c5e55a22574ea2212fe1
Git commit c785d0c9cb1dec7ddecc6225829879bf8a3210f1 by Noah Davis. Committed on 17/09/2024 at 18:53. Pushed by ndavis into branch 'release/24.08'. Round mouse positions to physical pixels At some point in the development of Plasma 6.0, mouse positions were changed to be fractional even on 1x scale screens. This is fine in some cases and not necessarily wrong, but it's bad for Spectacle since selection rectangles need to be snapped to physical pixels to make accurate selections. (cherry picked from commit 380303d4d096e0c7b206c5e55a22574ea2212fe1) Co-authored-by: Noah Davis <noahadvs@gmail.com> M +5 -0 src/Geometry.cpp M +6 -0 src/Geometry.h M +8 -6 src/Gui/Annotations/AnnotationViewport.cpp M +4 -2 src/Gui/Annotations/CropTool.qml M +2 -2 src/Gui/Annotations/SelectionTool.qml M +2 -2 src/Gui/Annotations/TextTool.qml M +6 -3 src/Gui/SelectionEditor.cpp M +5 -0 src/Gui/SpectacleWindow.cpp M +2 -1 src/Gui/SpectacleWindow.h https://invent.kde.org/graphics/spectacle/-/commit/c785d0c9cb1dec7ddecc6225829879bf8a3210f1
Hi. Sorry to necropost but my original issue is still unresolved so I'm re-opening this. The consistency of the sampling was solved, however the root issue (the sampling being between pixels) was not. This seems to not happen (or just bring to light an underlying issue) at 200% scaling.
Created attachment 179919 [details] Demonstration of the current behavior, as well as a comparison between 100% and 200% display scaling