With OpenGL turned off, the canvas resolution is at 200% instead of 100% when Windows is set to the default scaling of 200%. With Windows scaling set to 100% the canvas is displayed correctly at 100% resolution, but this renders the UI too small. Note: I usually find it preferable to turn OpenGL off when using Krita on the Surface, since drawing is smoother, and the device heats up uncomfortably (although Krita 3 seems to run quite warm even with OpenGL off, whereas 2.9x was notably cooler with it off). Reproducible: Always krita3-prealpha3-9694dac, Surface Pro4 265GB i5, 8GB RAM, Windows 10
Hm, that's likely to do with Qt 5.6' hiDpi feature: that checks on startup what the windows scaling factor is and follows it. Unless opengl is enabled, then the opengl widget has the native resolution. Weirdly enough, on my sp3, opengl makes painting a lot smoother...
That is weird. Definitely choppier here, especially at higher resolutions (e.g. 7000 x 4500). Should I make a separate report?
Hello, Dmitry suggested I add my input here! This also happens on the surface 3 (not pro). My scaling is set to 150% by default and I've never changed it. When openGL is enabled everything is really blurry-looking. When it's disabled it's fine, but each pixel is 2x the size as normal. I still haven't figured out how to disable scaling for Krita only. The UI is huge. Some dialogs get hidden under my taskbar now, such as when I open the color selector settings under Configure Krita. The size of the UI is fine on the previous pre-alpha for me. OpenGL makes it much smoother for me, as an aside. krita3-prealpha3-de0d43d, Surface 3 128gb, 4gb ram, windows 10
That sounds like we CANNOT use Qt 5.6's HiDPI support on Windows. It creates correct sized gui items, but also applies the scaling to the canvas, which then breaks. I wonder why it seems fine on OSX, which has a similar scaling method.
So, * with opengl off, the canvas is scaled to 200% * with opengl on, the canvas is scaled correctly, but since qt does the scaling, the result is blurry * for chris, turning opengl off makes painting smoother * for ramskulls, turning opengl on makes painting smoother I only have an SP3 to test on, and I don't observe a problem when painting with either opengl on or off, but the hidpi support does seem to be broken. http://doc.qt.io/qt-5/highdpi.html has information on playing with scaling approaches runtime, but I guess I should make the option to enable hidpi scaling automatically optional. Ideally, we'd let Qt handle scaling everything except for our canvas.
You're probably already on top of this, but on closer inspection I've found that the problem also occurs with OpenGL on, as ramskullsart@gmail.com described above. It's not quite as evident when zoomed out (which is how I usually work), however when zoom is set to 100% the canvas is actually displayed at 200%. This also affects many of the icons, as well as the popup palette, which appears as twice the normal size and half the resolution. The brush presets in the docker and the Advanced Color Selector are also blurry/low res.
Git commit 031c144cce1c5ec2898aeb4df9480e312c4c78ef by Boudewijn Rempt. Committed on 02/04/2016 at 14:03. Pushed by rempt into branch 'master'. Disable Qt's hidpi flag for now Weird stuff happens to the ui elements, and even weirder stuff to both the QPainter and the OpenGL canvas. M +4 -3 krita/main.cc http://commits.kde.org/krita/031c144cce1c5ec2898aeb4df9480e312c4c78ef
Git commit d0f04e304cf24776d57c3679c43533a57812a8a3 by Boudewijn Rempt. Committed on 05/04/2016 at 10:49. Pushed by rempt into branch 'rempt-osx-port'. Disable Qt's hidpi flag for now Weird stuff happens to the ui elements, and even weirder stuff to both the QPainter and the OpenGL canvas. M +4 -3 krita/main.cc http://commits.kde.org/krita/d0f04e304cf24776d57c3679c43533a57812a8a3
Created attachment 98319 [details] Image size fields squashed I'm posting this here since it's probably a side effect of the hidpi flag being disabled. 2.99.89.0 fixes the blurry/low res canvas and icons issue, but presents a couple of new problems on the Surface Pro 4: 1. The Image Size entry fields are squashed shut, making it impossible to set a new custom image size (see attachment). 2. The toolbox icons are now tiny, and selecting a larger size just spaces them further apart.
Image fields are also squashed for me. Can confirm changing icon size just spaces them apart, for sizes larger than 16x16.
are you both running at 200%?
I'm at 200%.
I'm at 150%.
I've asked on the Qt mailing list about it...
Git commit 61e9950d97fe1fe15c2b20d494ac80dfa8e29c71 by Boudewijn Rempt. Committed on 14/04/2016 at 14:15. Pushed by rempt into branch 'master'. Do not hardcode a max size for the image group This will make the whole group extremely squashed on hidpi screens. Related: bug 361736 M +5 -14 libs/ui/forms/wdgnewimage.ui http://commits.kde.org/krita/61e9950d97fe1fe15c2b20d494ac80dfa8e29c71
https://phabricator.kde.org/T2299
Git commit 0ed8060b7ec8535e92645e43e8766c19b00fc5d4 by Boudewijn Rempt. Committed on 14/05/2016 at 14:26. Pushed by rempt into branch 'rempt-opengl-check2'. Allow users to enabvle the hidpi support by setting an environment variable If you het KRITA_HIDPI to whatever, then Krita will enable Qt's (broken) hidpi support. All widgets will be fine, your canvas will be borked. M +6 -4 krita/main.cc http://commits.kde.org/krita/0ed8060b7ec8535e92645e43e8766c19b00fc5d4
Git commit 0d0edba4133616839548123e7578307c729c4063 by Boudewijn Rempt. Committed on 15/05/2016 at 10:45. Pushed by rempt into branch 'master'. Allow users to enabvle the hidpi support by setting an environment variable If you het KRITA_HIDPI to whatever, then Krita will enable Qt's (broken) hidpi support. All widgets will be fine, your canvas will be borked. M +6 -4 krita/main.cc http://commits.kde.org/krita/0d0edba4133616839548123e7578307c729c4063
Some notes from a discussion with Qt people: Date: Thu, 26 May 2016 15:55:17 +0200 From: Frederik Gladhorn <frederik.gladhorn@qt.io> To: Boudewijn Rempt <boud@kde.org>, Morten Sorvig <morten.sorvig@qt.io> Subject: Krita and high dpi canvas painting Hello Boud, hello Morten, after I chatted with each of you, I thought I'd just get you in touch. Morten was interested in the scaling issues with regards to the Krita canvas. Since he did most of the Qt work on High DPI, I'm sure he has ideas how to make things work smoothly. I guess it's best if you can give a description of the issues Krita is facing, I don't want to play man in the middle ;) Cheers, ===== Date: Thu, 26 May 2016 18:18:05 +0200 (CEST) From: Boudewijn Rempt <boud@valdyas.org> To: Frederik Gladhorn <frederik.gladhorn@qt.io> Cc: Boudewijn Rempt <boud@kde.org>, Morten Sorvig <morten.sorvig@qt.io>, dimula73@gmail.com Subject: Re: Krita and high dpi canvas painting Hi! Dmitry has digged in a bit deeper, so I've cc'ed him so he can chime in as well. On OSX there doesn't seem to be a problem, at least not for the opengl canvas. On Windows, this is the basic issue: https://bugs.kde.org/show_bug.cgi?id=360541 It's testable with the latest dev builds, by setting the KRITA_HIDPI environment variable to something -- if it's set, AA_EnableHighDpiScaling is set. Users complain that if they enable 150% or 200% display scaling both the opengl-based and the cpu, qpainter-based canvas are wrong: the image is also displayed at 150% or 200%. This is the same image at 100% zoom with scaling: http://imgur.com/shQ8iyw And this is without the option set: http://imgur.com/VqoSg59 Dmitry probably can explain what he thinks Qt is doing better than me, but basically, we want to render at the real, physical dpi of the screen, and zoom the image using our high-quality (that's the name, but it's pretty good) scaling shader. The qpainter-based canvas is probably less important for us, but from what I hear from Frederik might actually be easier to fix by just using the floating point qpainter api, but with opengl we of course cannot use the qpainter api for the image itself. (And for the canvas decoration, the opengl qpainter engine needs to be ported to 3.0 core profile, but we've got a summer of code student for that!) On Thu, 26 May 2016, Frederik Gladhorn wrote: > Hello Boud, hello Morten, > > after I chatted with each of you, I thought I'd just get you in touch. > Morten was interested in the scaling issues with regards to the Krita canvas. > Since he did most of the Qt work on High DPI, I'm sure he has ideas how to > make things work smoothly. > > I guess it's best if you can give a description of the issues Krita is facing, > I don't want to play man in the middle ;) > > Cheers, > Frederik > > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org [ALL of mess ===== Date: Fri, 27 May 2016 13:13:25 +0000 From: Morten Sorvig <Morten.Sorvig@qt.io> To: Boudewijn Rempt <boud@valdyas.org> Cc: Frederik Gladhorn <Frederik.Gladhorn@qt.io>, Boudewijn Rempt <boud@kde.org>, "dimula73@gmail.com" <dimula73@gmail.com> Subject: Re: Krita and high dpi canvas painting Hello! > On 26 May 2016, at 18:18, Boudewijn Rempt <boud@valdyas.org> wrote: > > Hi! > > Dmitry has digged in a bit deeper, so I've cc'ed him so he can chime in > as well. On OSX there doesn't seem to be a problem, at least not for the > opengl canvas. On Windows, this is the basic issue: > > https://bugs.kde.org/show_bug.cgi?id=360541 I’m also a bit surprised that there is a difference between Windows and OS X in this regard, so this is something to look further into. > > It's testable with the latest dev builds, by setting the KRITA_HIDPI > environment variable to something -- if it's set, AA_EnableHighDpiScaling > is set. I’ll download a dev build and test. > Dmitry probably can explain what he thinks Qt is doing better than me, > but basically, we want to render at the real, physical dpi of the screen, > and zoom the image using our high-quality (that's the name, but it's > pretty good) scaling shader. The good news here is that OpenGL works in the physical display pixel coordinate system, so you should be able to run the shader like you want to. Inputs/coordinates from the GUI side needs to be scaled for calls like glViewport(). See for example hellowindow.cpp from qtbase/examples/opengl/hellowindow. > > The qpainter-based canvas is probably less important for us, but from > what I hear from Frederik might actually be easier to fix by just using > the floating point qpainter api, but with opengl we of course cannot > use the qpainter api for the image itself. QPainter input coordinates are in the logical (scaled) coordinate system. It will rasterize at the full physical resolution. But if you want to provide inputs at the display resolution then floating point is the way to go. > > (And for the canvas decoration, the opengl qpainter engine needs to be > ported to 3.0 core profile, but we've got a summer of code student > for that!) Nice! Morten =========== Date: Tue, 31 May 2016 12:12:20 +0000 From: Morten Sorvig <Morten.Sorvig@qt.io> To: Boudewijn Rempt <boud@valdyas.org> Cc: Frederik Gladhorn <Frederik.Gladhorn@qt.io>, "dimula73@gmail.com" <dimula73@gmail.com> Subject: Re: Krita and high dpi canvas painting > On 27 May 2016, at 15:23, Boudewijn Rempt <boud@valdyas.org> wrote: > > On Fri, 27 May 2016, Morten Sorvig wrote: > >> I’ll download a dev build and test. > > I made new ones only last night: > > http://files.kde.org/krita/3/windows/devbuilds/krita-3.0-RC-1-master-7785651-x64.zip Hello again, After testing a bit on OS X and Windows I don’t really see a difference between the platforms. Note that I don’t know if I’m testing the OpenGL canvas or not. Is there a setting for it? What I did was manually adjusting the the scale factor by setting the QT_SCALE_FACTOR environment variable. I also tested with KRITA_HIDPI, there should be no difference to the application. What I see is that increasing the scale factor decreases the visual area available for Krita. (everything else being equal - in real use the increase in scale factor will have a corresponding increase in display pixel density, giving constant available visual area). This default behavior is good for the UI but might not be what’s best for the canvas. Here’s a summary of the options: 1) Constant visual size: Moving the application window from a 1x to a 2x display shows the same amount of canvas content. Content is rendered in finer detail at zoom < 100%. 2) Full physical pixel usage: Moving the application window from a 1x to a 2x monitor shows more content, effectively using the full physical pixel density to display as much as possible of the canvas at a given zoom level. Implementing option 2 takes some extra effort: The geometry you get from the QWidget API will be in logical pixels, which you then scale by QPaintDevice::devicePixelRatioF() or QWindow::devicePixelRatio() to get geometry in physical pixels. (at least for the OpenGL canvans) This is something we could look further into, although I don’t know how much help I can be with he Krita code base. Morten ============== Date: Wed, 1 Jun 2016 16:30:17 +0300 From: Dmitry Kazakov <dimula73@gmail.com> To: Boudewijn Rempt <boud@valdyas.org> Cc: Morten Sorvig <Morten.Sorvig@qt.io>, Frederik Gladhorn <Frederik.Gladhorn@qt.io> Subject: Re: Krita and high dpi canvas painting Parts/Attachments: 1 Shown 60 lines Text 2 OK ~56 lines Text ---------------------------------------- Hello! I might be a bit out of the context now. The last time I checked how openGL works I fond the following structure: 1) For most of the widgets the application writes to the local widget's (or window's) framebuffer. 2) Then the framebuffer is painted on the final application window using the some Qt's internal algorithm. 3) As far as I understood, this internal widget's framebuffer is painted on screen using the scaling transformation, which is basically the global Qt's scaling factor. To implement the correct zooming for Krita I need to know only one answer: Does Qt scales the framebuffer of the QOpenGLWidget? And if yes, how to disable it for a specific widget? According to Boud's screenshots, the scaling happens. That is not what we want, because the user's image becomes blurry. We use special shaders to render the image sharply on any small display and all this work is destroyed by further upscaling it :( So basically, I just need a way to disable this scaling for a QOpenGLWIdget. ============= Date: Thu, 2 Jun 2016 11:51:09 +0000 From: Morten Sorvig <Morten.Sorvig@qt.io> To: Dmitry Kazakov <dimula73@gmail.com> Cc: Boudewijn Rempt <boud@valdyas.org>, Frederik Gladhorn <Frederik.Gladhorn@qt.io> Subject: Re: Krita and high dpi canvas painting > On 01 Jun 2016, at 15:30, Dmitry Kazakov <dimula73@gmail.com> wrote: > > > To implement the correct zooming for Krita I need to know only one answer: > > Does Qt scales the framebuffer of the QOpenGLWidget? And if yes, how to disable it for a specific widget? Hi, The short answer is that Qt does not (or is not supposed to) scale the OpenGL framebuffer. The fragment shaders will run for each display pixel, and there is no upscaling of the result. Here’s a screenshot at ‘ridiculous’ scale (4x using QT_SCALE_FACTOR): http://imgur.com/PuhMHXA This should make it clear which parts of the UI are rendered at full resolution (text, canvas, some icons) and not (color selector, some other icons). So this was a “works for me” answer :) I you are seeing blurry canvas output on some platform/config then let’s look at that. Morten ======= ALPINE 2.00 MESSAGE TEXT [A] <Mail> saved-messages Msg 2,672 of 2,998 ALL Date: Thu, 2 Jun 2016 12:32:10 +0000 From: Morten Sorvig <Morten.Sorvig@qt.io> To: Boudewijn Rempt <boud@valdyas.org> Cc: Frederik Gladhorn <Frederik.Gladhorn@qt.io>, "dimula73@gmail.com" <dimula73@gmail.com> Subject: Re: Krita and high dpi canvas painting > On 31 May 2016, at 14:50, Boudewijn Rempt <boud@valdyas.org> wrote: > > On Tue, 31 May 2016, Morten Sorvig wrote: > >> 1) Constant visual size: Moving the application window from a 1x to a 2x display shows the same amount of canvas content. Content is rendered in finer detail at zoom < 100%. >> >> 2) Full physical pixel usage: Moving the application window from a 1x to a 2x monitor shows more content, effectively using the full physical pixel density to display as much as possible of the canvas at a given zoom level. >> >> Implementing option 2 takes some extra effort: The geometry you get from the QWidget API will be in logical pixels, which you then scale by QPaintDevice::devicePixelRatioF() or QWindow::devicePixelRatio() to get geometry in physical pixels. (at least for the OpenGL canvans) >> > > I'm so confused now... Thinking again, I guess it's 2) we need, but we'll need to calculate the scaling factor so the image is always shown at the right resolution: if the 1x and 2x monitors have the same physical size, we should show the same amount of image. > So when moving between 1x and 2x monitors of equal physical size the scale factor and physical pixel density changes in sync, and we show the same amount of image. The reason for the Windows bug reports may be that when changing the Windows scaling you are (obviously) not changing the pixel density of the monitor at the same time. So the behavior where higher scaling percentages show less content is expected, because: - a 3840x2160 monitor at 100% is large and should show more content. - a 3840x2160 monitor at 250% is smaller and should show less content. (This is assuming the monitor scaling is correctly configured for its physical size) If this makes sense then the good news may be that no code changes are needed. Morten =======
*** Bug 388233 has been marked as a duplicate of this bug. ***
Created attachment 109575 [details] Krita at 100% scaled
Created attachment 109576 [details] Krita at 150% scaled
Created attachment 109577 [details] Krita at 200%scaled Since there is no difference between 150% and 200% scaled, I guess we should just apply a 50% zoom factor in the opengl canvas when display scaling is on, on Windows...
(In reply to Boudewijn Rempt from comment #23) > > Since there is no difference between 150% and 200% scaled, I guess we should > just apply a 50% zoom factor in the opengl canvas when display scaling is > on, on Windows... No, there is a proper way to get the device scale factor (`devicePixelRatio` or `devicePixelRatioF`). Qt currently rounds the scale factor to integral values (so 150% gets 2x) but it can change in the future so 150% can get 1.5x instead. 300% is also possible as of now, so 2x isn't the only possible value. I did proposed dividing the zoom factor by the scale factor, but Dmitry disagreed with it. There's also more to consider than just the zoom factor. I believe this and the later comments on https://phabricator.kde.org/T2299#111948 has summed up most of the issues.
*** Bug 393642 has been marked as a duplicate of this bug. ***
Created attachment 115279 [details] Krita 200% scaled with small buttons (CentOS) I'm using Krita 4.1.3 from Flathub on CentOS with a 27" 4K display. I noticed the buttons in the previous screenshot with 200% scaling from Windows all look to be a good size, whereas mine are quite small. Is this a known issue on Linux?
Comment on attachment 115279 [details] Krita 200% scaled with small buttons (CentOS) I'm on Linux Mint Cinnamon, and right now, I have "Hi-DPI mode off. I was having tablet issues with Hi-DPI mode and was "bearing and gritting it" for a while. While I have a 4k screen, things are functioning properly for me, albeit a good number of screen elements are tiny. Here's how I coped with it: I have the tools on the left set to "48x48". (Right click on the tools and select a size you like.) Also, in Krita (nightly build git e94e365), the layers docker seem to have been updated, slightly. Whether it was intentional or a glitch, is up in the air to me, but I am enjoying it because my layout looks similar to if I had "Hi-DPI" mode enabled. --- The words are spaced out properly compared to before this build when the words were "crammed" together. The Krita team is working on Hi-DPI scaling, but right now their main focus is bug fixes. I'm fairly certain that they will return to Hi-DPI issues in the future. :)
Git commit 9d95d8d5386eecba733392c5514f230c82f65ee5 by Dmitry Kazakov. Committed on 07/10/2018 at 21:50. Pushed by dkazakov into branch 'master'. Fix canvas scale in HiDPI mode Qt has a bit complicated way to deal with openGL widget in scaled HiDPI mode. The openGL widget's framebuffer is stored in hardware pixels (physical coordinates), but before calling paintGL, Qt sets manual scaling with glOrtho that makes this FBO look as if it is stored in logical pixels. This patch basically takes it into account by setting a correct physical resolution in KisZoomManager::updateScreenResolution(). It has one non- trivial consequence. Now, when setting zoom to 100% and having pixel aspect mode activated, Flake coordinate system does **not** have 100% zoom, because it is measured in logical coordinates, but not in physical ones, which are bigger. Fixes T2299 M +1 -1 libs/ui/KisMainWindow.cpp M +3 -0 libs/ui/KisMainWindow.h M +7 -0 libs/ui/KisView.cpp M +2 -0 libs/ui/KisView.h M +1 -0 libs/ui/canvas/kis_canvas2.cpp M +19 -1 libs/ui/canvas/kis_coordinates_converter.cpp M +2 -0 libs/ui/canvas/kis_coordinates_converter.h M +32 -5 libs/ui/kis_zoom_manager.cc M +6 -0 libs/ui/kis_zoom_manager.h M +2 -1 libs/ui/opengl/kis_opengl_canvas2.cpp https://commits.kde.org/krita/9d95d8d5386eecba733392c5514f230c82f65ee5
Git commit 3d77d9f5bae507e8461acc846389bac207849bb5 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 10/10/2018 at 07:40. Pushed by rempt into branch 'krita/4.1'. Fix canvas scale in HiDPI mode Qt has a bit complicated way to deal with openGL widget in scaled HiDPI mode. The openGL widget's framebuffer is stored in hardware pixels (physical coordinates), but before calling paintGL, Qt sets manual scaling with glOrtho that makes this FBO look as if it is stored in logical pixels. This patch basically takes it into account by setting a correct physical resolution in KisZoomManager::updateScreenResolution(). It has one non- trivial consequence. Now, when setting zoom to 100% and having pixel aspect mode activated, Flake coordinate system does **not** have 100% zoom, because it is measured in logical coordinates, but not in physical ones, which are bigger. Fixes T2299 (cherry picked from commit 9d95d8d5386eecba733392c5514f230c82f65ee5) M +1 -1 libs/ui/KisMainWindow.cpp M +3 -0 libs/ui/KisMainWindow.h M +7 -0 libs/ui/KisView.cpp M +2 -0 libs/ui/KisView.h M +1 -0 libs/ui/canvas/kis_canvas2.cpp M +19 -1 libs/ui/canvas/kis_coordinates_converter.cpp M +2 -0 libs/ui/canvas/kis_coordinates_converter.h M +32 -5 libs/ui/kis_zoom_manager.cc M +6 -0 libs/ui/kis_zoom_manager.h M +2 -1 libs/ui/opengl/kis_opengl_canvas2.cpp https://commits.kde.org/krita/3d77d9f5bae507e8461acc846389bac207849bb5