Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 14, 2019 at 09:10:22PM +0200, Tobias Frost wrote: > On Wed, Aug 07, 2019 at 07:00:23AM +0100, Olly Betts wrote: > > Which makes me wonder - can one explicitly set GDK_SCALE=1 to workaround > > the problem when using a hidpi display? Presumably that results in any > > non-OpenGL content in the window being smaller than ideal, but probably > > it's like that anyway if one sticks with GTK2. > > Indeed, that works. And yes, other stuff gets tiny (e.g. buttons and their > icons), but this issue is (still but) less painful than the other… I've backported the change to make wxWindow::GetContentScaleFactor() return an appropriate value with hidpi, instead of always reporting 1.0. This has been applied to upstream's WX_3_0_BRANCH and I've uploaded a new wxwidgets3.0 package containing it. So applications which have been adjusted to use API method to support hidpi under wxWidgets 3.1.x should now behave better under 3.0.x too. There are quite a lot of other changes related to hidpi on upstream git master which haven't been backported though. If you hit further problems under hidpi, please report them and we can investigate and decide if we should try to find and backport fixes, or go the GDK_SCALE=1 route for wx 3.0.x and wait for upstream to release 3.2.0 to get proper hidpi support. Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 07:00:23AM +0100, Olly Betts wrote: > On Wed, Aug 07, 2019 at 06:14:45AM +0100, Olly Betts wrote: > > On Wed, Aug 07, 2019 at 06:04:58AM +0100, Olly Betts wrote: > > > I don't have a hidpi display and don't know if it's possible to simulate > > > one. I don't run Gnome either... > > > > Aha, I see in https://trac.wxwidgets.org/ticket/17391 that one can > > simulate with e.g. GDK_SCALE=2 in the environment. > > Which makes me wonder - can one explicitly set GDK_SCALE=1 to workaround > the problem when using a hidpi display? Presumably that results in any > non-OpenGL content in the window being smaller than ideal, but probably > it's like that anyway if one sticks with GTK2. Indeed, that works. And yes, other stuff gets tiny (e.g. buttons and their icons), but this issue is (still but) less painful than the other… > Cheers, > Olly -- tobi
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 06:14:45AM +0100, Olly Betts wrote: > On Wed, Aug 07, 2019 at 06:04:58AM +0100, Olly Betts wrote: > > I don't have a hidpi display and don't know if it's possible to simulate > > one. I don't run Gnome either... > > Aha, I see in https://trac.wxwidgets.org/ticket/17391 that one can > simulate with e.g. GDK_SCALE=2 in the environment. Which makes me wonder - can one explicitly set GDK_SCALE=1 to workaround the problem when using a hidpi display? Presumably that results in any non-OpenGL content in the window being smaller than ideal, but probably it's like that anyway if one sticks with GTK2. Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 12:14:30AM -0400, Scott Talbert wrote: > On Thu, 1 Aug 2019, Tobias Frost wrote: > > > I could get Gnome to offer me the scaling issue on my Desktop PC with a > > full HD monitor, so maybe that is a possiblity. > > > > Some obervations on the bug: > > Only the drawing seems to be botched. Mouse coordinates seem to be > > matching with the window area, so e.g to select an object in slic3r you > > would have put the mouse in the middle of the window area, not in the middle > > where it is rendered. IOW, it seems that the coordinates to be rendered > > are somewhere not using the scaling factor… > > > > PS: https://github.com/prusa3d/PrusaSlicer/issues/864 seems related, > > and it seems to be fixed^Wbetter in wxwidgets 3.1 … > > Okay, so I think I better understand this problem now. It seems that all of > these applications are using wxGLCanvas. When using OpenGL, apparently it > operates on physical pixels, so when setting the dimensions of the GL > viewport, the scale factor of the display has to be factored in. Thus, > darkradiant (and these other applications) will have to use the scale factor > when calling glViewport(). Does this affect anything using wxGLCanvas? Or does it depend on how the viewport is set or something? I don't have a hidpi display and don't know if it's possible to simulate one. I don't run Gnome either... > Now, the harder part is getting the current scale factor. In wx 3.1, you > can call GetContentScaleFactor(). However, in wx 3.0, this always returns > 1. In order to fix that, we would need at least part of this commit: > https://github.com/wxWidgets/wxWidgets/commit/f95fd11e08482697c3b0c0a9d2ccd661134480ee#diff-40dd4b5e2cdfa858afee852fae756e01 > However, I don't know if that would cause an ABI change - does adding a new > override of a C++ function change ABI? If so, then we would probably need > some other way of solving this. This is discussed here: https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B | You can... | [...] | reimplement virtual functions defined in the primary base class | hierarchy (that is, virtuals defined in the first non-virtual base | class, or in that class's first non-virtual base class, and so forth) if | it is safe that programs linked with the prior version of the library | call the implementation in the base class rather than the derived one. | This is tricky and might be dangerous. Think twice before doing it. | Alternatively see below for a workaround. | | Exception: if the overriding function has a covariant return type, | it's only a binary-compatible change if the more-derived type has | always the same pointer address as the less-derived one. If in | doubt, do not override with a covariant return type. So if the compiler has optimised the call for an already built application, it would still get a scale factor of 1.0. Not terrible in isolation, but if there are multiple calls and only some are optimised that would probably be problematic. We could plan to binNMU affected programs, but that's not ideal (and doesn't help for non-packaged applications built by users). To address it just within Debian, we could potentially add a new non-virtual method to return this for 3.0.x, and patch affected applications to call that method instead until 3.2.x. Or maybe see if upstream think it's worth finding a way to address? Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Wed, Aug 07, 2019 at 06:04:58AM +0100, Olly Betts wrote: > I don't have a hidpi display and don't know if it's possible to simulate > one. I don't run Gnome either... Aha, I see in https://trac.wxwidgets.org/ticket/17391 that one can simulate with e.g. GDK_SCALE=2 in the environment. Cheers, Olly
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
On Thu, 1 Aug 2019, Tobias Frost wrote: I could get Gnome to offer me the scaling issue on my Desktop PC with a full HD monitor, so maybe that is a possiblity. Some obervations on the bug: Only the drawing seems to be botched. Mouse coordinates seem to be matching with the window area, so e.g to select an object in slic3r you would have put the mouse in the middle of the window area, not in the middle where it is rendered. IOW, it seems that the coordinates to be rendered are somewhere not using the scaling factor… PS: https://github.com/prusa3d/PrusaSlicer/issues/864 seems related, and it seems to be fixed^Wbetter in wxwidgets 3.1 … Okay, so I think I better understand this problem now. It seems that all of these applications are using wxGLCanvas. When using OpenGL, apparently it operates on physical pixels, so when setting the dimensions of the GL viewport, the scale factor of the display has to be factored in. Thus, darkradiant (and these other applications) will have to use the scale factor when calling glViewport(). Now, the harder part is getting the current scale factor. In wx 3.1, you can call GetContentScaleFactor(). However, in wx 3.0, this always returns 1. In order to fix that, we would need at least part of this commit: https://github.com/wxWidgets/wxWidgets/commit/f95fd11e08482697c3b0c0a9d2ccd661134480ee#diff-40dd4b5e2cdfa858afee852fae756e01 However, I don't know if that would cause an ABI change - does adding a new override of a C++ function change ABI? If so, then we would probably need some other way of solving this. Scott
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
Package: src:wxwidgets3.0 Followup-For: Bug #933554 (Moving the subdiscussion from #933419) > Is this same bug that you've written up recently as #933554? I don't > have a Debian system with a HiDPI display, but I should probably be > able to test on another OS. I could get Gnome to offer me the scaling issue on my Desktop PC with a full HD monitor, so maybe that is a possiblity. Some obervations on the bug: Only the drawing seems to be botched. Mouse coordinates seem to be matching with the window area, so e.g to select an object in slic3r you would have put the mouse in the middle of the window area, not in the middle where it is rendered. IOW, it seems that the coordinates to be rendered are somewhere not using the scaling factor… PS: https://github.com/prusa3d/PrusaSlicer/issues/864 seems related, and it seems to be fixed^Wbetter in wxwidgets 3.1 … -- tobi
Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3
Package: src:wxwidgets3.0 Severity: normal Control: affects -1 slic3r slic3r-prusa Control: block 933419 by -1 (I'm sorry, I don't know how that widget is called… Please retitle the bug accordingly) On e.g darkradiant, slic3r and slic3r-prusa (and maybe others), when the gnome scaling feature is enabled, e.g because you've got an QHD+ display, the widget does not fill its dedicated space but only a quarter of it (e.g when scaling is 200%). Please see the two screenshots I've placed on my server: Scaling 200%: https://sviech.de/index.php/s/ryQNS5cdKKfPkBc Scaling 100%: https://sviech.de/index.php/s/CzZ65d8ysANyDCA (note: this a non-uploaded darkradiant re-compiled with GTK3 support, the archives have still version 2.6.0-3+b1 compiled against GTK2, see #933419) It is not Wayland related, I can also see the issue using X11 Cheers, tobi -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled