https://bugs.kde.org/show_bug.cgi?id=360541
--- Comment #19 from Boudewijn Rempt <b...@valdyas.org> --- Some notes from a discussion with Qt people: Date: Thu, 26 May 2016 15:55:17 +0200 From: Frederik Gladhorn <frederik.gladh...@qt.io> To: Boudewijn Rempt <b...@kde.org>, Morten Sorvig <morten.sor...@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 <b...@valdyas.org> To: Frederik Gladhorn <frederik.gladh...@qt.io> Cc: Boudewijn Rempt <b...@kde.org>, Morten Sorvig <morten.sor...@qt.io>, dimul...@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.sor...@qt.io> To: Boudewijn Rempt <b...@valdyas.org> Cc: Frederik Gladhorn <frederik.gladh...@qt.io>, Boudewijn Rempt <b...@kde.org>, "dimul...@gmail.com" <dimul...@gmail.com> Subject: Re: Krita and high dpi canvas painting Hello! > On 26 May 2016, at 18:18, Boudewijn Rempt <b...@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.sor...@qt.io> To: Boudewijn Rempt <b...@valdyas.org> Cc: Frederik Gladhorn <frederik.gladh...@qt.io>, "dimul...@gmail.com" <dimul...@gmail.com> Subject: Re: Krita and high dpi canvas painting > On 27 May 2016, at 15:23, Boudewijn Rempt <b...@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 <dimul...@gmail.com> To: Boudewijn Rempt <b...@valdyas.org> Cc: Morten Sorvig <morten.sor...@qt.io>, Frederik Gladhorn <frederik.gladh...@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.sor...@qt.io> To: Dmitry Kazakov <dimul...@gmail.com> Cc: Boudewijn Rempt <b...@valdyas.org>, Frederik Gladhorn <frederik.gladh...@qt.io> Subject: Re: Krita and high dpi canvas painting > On 01 Jun 2016, at 15:30, Dmitry Kazakov <dimul...@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.sor...@qt.io> To: Boudewijn Rempt <b...@valdyas.org> Cc: Frederik Gladhorn <frederik.gladh...@qt.io>, "dimul...@gmail.com" <dimul...@gmail.com> Subject: Re: Krita and high dpi canvas painting > On 31 May 2016, at 14:50, Boudewijn Rempt <b...@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 ======= -- You are receiving this mail because: You are watching all bug changes.
