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
