Bug 441232

Created attachment 140870 [details]
Shows how cursor works fine in 4.4.3 on the same system

Update:
Managed to work around this issue by turning off options for Hi-DPI under "Configure Krita/General/Window"

Cannot reproduce. Can you provide the information from "Help -> Show system information for bug reports" from 4.4.7 *with hi-dpi enabled*?

(In reply to Alvin Wong from comment #3)
> Cannot reproduce. Can you provide the information from "Help -> Show system
> information for bug reports" from 4.4.7 *with hi-dpi enabled*?

Hi Alvin,
yes of course. Pasting my system info below.
After a bit more investigation I can see that the culprit is my dual screen setup. Windows seems to be scaling one of my displays by 125% and that seems to trigger the issue. 


Krita

 Version: 4.4.7
 Languages: en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.11
  Version (loaded): 5.12.11

OS Information

  Build ABI: x86_64-little_endian-llp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: winnt
  Kernel Version: 10.0.19042
  Pretty Productname: Windows 10 (10.0)
  Product Type: windows
  Product Version: 10

OpenGL Info
 
  Vendor:  "Google Inc." 
  Renderer:  "ANGLE (NVIDIA GeForce RTX 2070 Super Direct3D11 vs_5_0 ps_5_0)" 
  Version:  "OpenGL ES 3.0 (ANGLE 2.1.0.57ea533f79a7)" 
  Shading language:  "OpenGL ES GLSL ES 3.00 (ANGLE 2.1.0.57ea533f79a7)" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::CompatibilityProfile) 
  Current format:    QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples 0, swapBehavior QSurfaceFormat::DefaultSwapBehavior, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile  QSurfaceFormat::NoProfile) 
     Version: 3.0
     Supports deprecated functions false 
     is OpenGL ES: true 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsAngleD3D11: true 
  isQtPreferAngle: true 

Hardware Information

  GPU Acceleration: auto
  Memory: 65320 Mb
  Number of Cores: 16
  Swap Location: C:/Users/ext-KTysdal/AppData/Local/Temp

Current Settings

  Current Swap Location: C:/Users/ext-KTysdal/AppData/Local/Temp
  Current Swap Location writable: true
  Undo Enabled: true
  Undo Stack Limit: 30
  Use OpenGL: true
  Use OpenGL Texture Buffer: true
  Use AMD Vectorization Workaround: false
  Canvas State: OPENGL_SUCCESS
  Autosave Interval: 900
  Use Backup Files: true
  Number of Backups Kept: 1
  Backup File Suffix: ~
  Backup Location: Same Folder as the File
  Backup Location writable: false
  Use Win8 Pointer Input: true
  Use RightMiddleTabletButton Workaround: false
  Levels of Detail Enabled: false
  Use Zip64: false


Display Information
Number of screens: 2
	Screen: 0
		Name: \\.\DISPLAY4
		Depth: 32
		Scale: 1
		Resolution in pixels: 1920x1080
		Manufacturer: 
		Model: 
		Refresh Rate: 60
	Screen: 1
		Name: \\.\DISPLAY1
		Depth: 32
		Scale: 1.25
		Resolution in pixels: 1536x864
		Manufacturer: 
		Model: 
		Refresh Rate: 60

Thanks for your comment!

Automatically switching the status of this bug to REPORTED so that the KDE team
knows that the bug is ready to get confirmed.

In the future you may also do this yourself when providing needed information.

Putting this on the back burner.

Did you turn both hidpi options off, or only fractional scaling?

(In reply to Halla Rempt from comment #7)
> Did you turn both hidpi options off, or only fractional scaling?

I turned both hidpi options off in my initial test. However, I tested only turning off "fractional scaling" just now and that solved the issue as well. 

And as a third test I turned "fractional scaling" back on and then turned "Enable Hi-DPI support" off, and that also solved the issue.

So as far as I can tell, the corrupted cursor only happens when both Hi-DPI options are enabled.

Setting back to confirmed. Just FYI I've known that the cursor handling has been a bit broken with per-monitor scaling for quite some time, it just didn't occur to me that this is referencing the same issue, and this does require a 125% or 175% scaling to trigger.

*** Bug 433318 has been marked as a duplicate of this bug. ***

Git commit a33db56d6ef9eb46584e8be28685b7dcb15ab6f7 by Alvin Wong.
Committed on 06/04/2022 at 15:42.
Pushed by alvinwong into branch 'master'.

Change image-based cursors to be loaded as QPixmap

QBitmap-based cursors seems to be very buggy on Windows when high-DPI
scaling is in use. QPixmap-based cursors seems to work better and even
supports colour, so switch to that.

M  +3    -55   libs/widgetutils/kis_cursor_cache.cpp

https://invent.kde.org/graphics/krita/commit/a33db56d6ef9eb46584e8be28685b7dcb15ab6f7

Git commit af4e8a14fa98efbde2f7186b6687496da0233632 by Alvin Wong.
Committed on 06/04/2022 at 15:44.
Pushed by alvinwong into branch 'krita/5.0'.

Change image-based cursors to be loaded as QPixmap

QBitmap-based cursors seems to be very buggy on Windows when high-DPI
scaling is in use. QPixmap-based cursors seems to work better and even
supports colour, so switch to that.
(cherry picked from commit a33db56d6ef9eb46584e8be28685b7dcb15ab6f7)

M  +3    -55   libs/widgetutils/kis_cursor_cache.cpp

https://invent.kde.org/graphics/krita/commit/af4e8a14fa98efbde2f7186b6687496da0233632