Bug 429893 - Brush presets window closes when in hi-dpi support is enabled and multiple monitors have different scaling
Summary: Brush presets window closes when in hi-dpi support is enabled and multiple mo...
Status: RESOLVED NOT A BUG
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: 4.4.0
Platform: Compiled Sources Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-01 14:10 UTC by Shannon Poole
Modified: 2021-08-26 14:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Video demonstrating faulty behavior (503.09 KB, video/mp4)
2020-12-01 14:10 UTC, Shannon Poole
Details
System information (2.56 KB, text/plain)
2020-12-01 14:12 UTC, Shannon Poole
Details
Compatibility settings (63.85 KB, image/png)
2020-12-01 16:41 UTC, Shannon Poole
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Shannon Poole 2020-12-01 14:10:47 UTC
Created attachment 133769 [details]
Video demonstrating faulty behavior

SUMMARY

When Enable Hi-DPI support is on AND when using two monitors with different "Scale and layout" settings, clicking the Toggle showing presets button causes the Edit brush settings window to close and not reopen until the full Krita application window is resized in some way (e.g. maximize/un-maximise).

STEPS TO REPRODUCE
1. Make sure Enable Hi-DPI support is on in Krita
2. Set primary monitor's Scale and Layout to 150%
3. Set secondary monitor's Scale and Layout to 200%
4. Open krita and move to secondary monitor
5. Open brush settings menu
6. Click the Toggle showing presets button

OBSERVED RESULT

Brush settings menu window closes with no ability to reopen by clicking the button again, until the application window is resized

EXPECTED RESULT

Brush settings menu window should remain open and the presets section should expand or collapse

SOFTWARE/OS VERSIONS
Windows: Windows 10
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION

Changing the scale and layout to be the same for both monitors resolves the issue but the scaling may not match the recommended setting for the display size.
Comment 1 Shannon Poole 2020-12-01 14:12:04 UTC
Created attachment 133770 [details]
System information
Comment 2 Halla Rempt 2020-12-01 14:38:44 UTC
Hi,

Thanks for the detailed and really clear report. I haven't been able to reproduce, though. 

* Are you pressing the toggle button with a mouse, or with a stylus?

This is my system info:
Krita

 Version: 4.4.2-alpha (git 59c60f7)
 Languages: en_US, en
 Hidpi: true

Qt

  Version (compiled): 5.12.9
  Version (loaded): 5.12.9

OS Information

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

OpenGL Info
 
  Vendor:  "Google Inc." 
  Renderer:  "ANGLE (Intel(R) HD Graphics 630 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: 32604 Mb
  Number of Cores: 8
  Swap Location: C:/Users/boude/AppData/Local/Temp

Current Settings

  Current Swap Location: C:/Users/boude/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_NOT_TRIED
  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: false
  Use RightMiddleTabletButton Workaround: false
  Levels of Detail Enabled: false
  Use Zip64: false


Display Information
Number of screens: 3
	Screen: 0
		Name: \\.\DISPLAY2
		Depth: 32
		Scale: 1
		Resolution in pixels: 2560x1440
		Manufacturer: 
		Model: 
		Refresh Rate: 59
	Screen: 1
		Name: \\.\DISPLAY1
		Depth: 32
		Scale: 2
		Resolution in pixels: 1280x720
		Manufacturer: 
		Model: 
		Refresh Rate: 60
	Screen: 2
		Name: \\.\DISPLAY3
		Depth: 32
		Scale: 1
		Resolution in pixels: 2560x1440
		Manufacturer: 
		Model: 
		Refresh Rate: 59
Comment 3 Shannon Poole 2020-12-01 15:21:31 UTC
I tried both the mouse and the stylus and both result in the same behavior.

I've also noticed that I can change the scale on the secondary monitor to 150% to match the other monitor, without restarting Krita resize the window and it will then work from then on out. Even if I then set it back to 200%. This let's me get it working at the recommended display scaling but it requires many steps every time I start up Krita.
Comment 4 Shannon Poole 2020-12-01 15:27:21 UTC
Also, I can move Krita to the primary monitor when it's demonstrating the faulty behavior and it stops until I move it back to the secondary monitor. Very strange, but this is what lead me to believe it had something to do with the scaling because both my monitors are the same resolution.
Comment 5 Shannon Poole 2020-12-01 16:41:10 UTC
Created attachment 133777 [details]
Compatibility settings
Comment 6 Shannon Poole 2020-12-01 16:41:32 UTC
I think I may have found something. I had originally set the compatibility for Krita "High DPI scaling override" set to "Application" (screenshot attached). This was because I had a different monitor before and I was having trouble with the scaling. If I remove this option it behaves correctly and now looks correct with my new monitor.
Comment 7 Alvin Wong 2021-08-26 14:54:19 UTC
Hi, setting "High DPI scaling override" to "Application" *will* cause unintended behaviour with Qt that we can't do anything about. Since you figured this out, I am going to assume that this is resolved.