Created attachment 156480 [details] Screenshots showing the issue and ICC settings for reproduction of the issue. SUMMARY *** Situation: Windows 10 22H2 Two displays attached via Nvidia GPU displayport Display1 = Main in Windows Display2 = Secondary in Windows Krita 5.1.5 *** In Krita each display has an ICC profile assinged. When I open Krita on display1 and open an image, I get the expected color management according to the assigned ICC profile. When I then move the Krita GUI to display2 I get the expected switch to the ICC profile of display2. But, if I then move the Krita GUI back to display1, Krita does not switch back to the ICC profile of display1; instead it sticks to the profile of display2. STEPS TO REPRODUCE 1. in Krita's settings assign ICC profiles to display1 and display2. Use Krita's krita25_lcms-builtin-sRGB_g100-truegamma.icc for display1. This profile is intentionally wrong - it is used to trigger an obvious change of the image representation when this profile is used. Use a "correct" ICC profile for display2 (e.g. one created with a probe or a default sRGB profile). Set rendering intend to relative colorimetric. 2. Restart Krita on display1 3. Open an sRGB image with 8bit color depth. Because of the "wrong" linear profile assigned to display1 the image will look darker than it would with a correct sRGB profile. 4. Move the Krita GUI to display2. Krita switches its color managment to the ICC profile of display2. The image now looks correct. 5. Move the Krita GUI back to display1. Krita does not switch back to the ICC profile of display1 but keeps showing the image with the profile of display2. OBSERVED RESULT When moving Krita's GUI from display1 to display2 the ICC profile of display2 get used correctly. When moving the GUI back to display1 Krita sticks with the ICC profile of display2. EXPECTED RESULT When moving the GUI back to display1 the ICC profile of display1 should be used. SOFTWARE/OS VERSIONS Windows 10 22H2 ADDITIONAL INFORMATION Detailed thread on krita-artists.org with initial "how to"-question and further investigation of the issue. https://krita-artists.org/t/icc-profile-handling-when-moving-app-from-one-display-to-another/58184
Tested this with 5.1.5 and current master (commit 1cc4b8865c) under Windows 10 21H2. I've verified that the Display 1 gets (in) correctly darkened with sRGB, that switching to Display 2 "fixes" the rendering, and that switching back "breaks" the rendering again. HOWEVER, this only applies if I move the screen with Windows-Shift-Arrow. If I do so manually, the screen change doesn't kick in.
So I found that when the screen is midway across screens, QDesktopWidget::screenNumber is unable to resolve which screen the widget belongs to, and thus change the profile appropriately. This is a known documented bug, so marking as duplicate. *** This bug has been marked as a duplicate of bug 407498 ***
Actually, on second thought, this is a bit more insidious... merge request incoming. It affects more than just the canvas.
Thanks for the investigation. I can confirm that the workaround with shortcut combo Windows-key + shift + left / right arrow key triggers the profile switching as expected.
Git commit d01231403e5af8cc34c380ed50da50169db67001 by L. E. Segovia. Committed on 24/02/2023 at 13:32. Pushed by lsegovia into branch 'master'. ui: Fix inconsistent misdetection of screen number The reason why sometimes the widget change of screen wasn't detected was because the check must be run on the main window, not on the canvas widget. The previous commit, as well as the use of screenNumber, lets me trace all affected users of this check. While at it, ensure that all known users of QApplication::activeWindow in context with KisConfig::displayProfile won't crash if something goes wrong. M +2 -6 libs/ui/canvas/kis_canvas2.cpp M +2 -2 libs/ui/kis_clipboard.cc M +1 -1 libs/ui/kis_mimedata.cpp M +2 -2 libs/ui/toolbox/KoToolBox.cpp M +1 -1 libs/ui/widgets/KisScreenColorSampler.cpp M +1 -1 libs/ui/widgets/kis_scratch_pad.cpp M +1 -1 plugins/tools/svgtexttool/SvgTextEditor.cpp https://invent.kde.org/graphics/krita/commit/d01231403e5af8cc34c380ed50da50169db67001
Git commit 282a491991e8df0e8545a4edf24eb5444a3dded0 by L. E. Segovia. Committed on 24/02/2023 at 13:32. Pushed by lsegovia into branch 'master'. KisMainWindow: enable tracing the screenChanged signal through IntelliSense M +3 -3 libs/ui/KisMainWindow.cpp M +1 -1 libs/ui/canvas/kis_canvas2.cpp https://invent.kde.org/graphics/krita/commit/282a491991e8df0e8545a4edf24eb5444a3dded0
Git commit 8355ae4ec082744be0614e238887540e8124d0aa by L. E. Segovia. Committed on 01/03/2023 at 01:52. Pushed by lsegovia into branch 'master'. KisMainWindow: emit screenChanged to act on display preferences change M +3 -0 libs/ui/KisMainWindow.cpp https://invent.kde.org/graphics/krita/commit/8355ae4ec082744be0614e238887540e8124d0aa