Bug#933554: [src:wxwidgets3.0] some widget broken when Gnome scaling is not 100%" on GTK3

2019-09-05 Thread Olly Betts
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

2019-08-14 Thread Tobias Frost
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

2019-08-07 Thread Olly Betts
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

2019-08-06 Thread Olly Betts
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

2019-08-06 Thread Olly Betts
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

2019-08-06 Thread Scott Talbert

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

2019-08-01 Thread Tobias Frost
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

2019-07-31 Thread Tobias Frost
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