Aven on hiDPI screens

[Olly Betts]

On Wed, Sep 08, 2021 at 03:56:02PM +0100, Wookey wrote:
> Below is my patch. Can anyone who groks C++ tell me what I'm doing
> wrong in terms of scope?

GetContentScaleFactor() is a method of wxWindow, but you aren't calling
it on a wxWindow.  You're calling it in main() so there's not even a
this pointer.

I assume the scale factor is per window to allow for having a hidpi and
a normal screen attached at the same time.  No idea how it handles
a window straddling the two though...

> So instead I tried just putting '2' as the scaling factor and it
> doesn't seem to work either, so this may be the wrong approach.

Scope isn't really your problem - your patch appears to be trying to
just make the default size of the main window two (or whatever) times
larger in each direction, and doing that won't solve the problem.
(I'd think the initial window sizing should just work automatically as
it is based on the reported screen dimensions which I'd expect to just
work, but if the initial window sizing when there's no existing ~/.aven
is wrong we can adjust that, but I guess we'd have to create the window
first to call GetContentScaleFactor() on it.)

The known issues are with the OpenGL pane inside that window.  The parent
window should ensure that this pane is sized to fill the space available
for it, so I doubt it's the size of this pane either.  I think the first
problem is that the reported size of the pane needs scaling for OpenGL:

diff --git a/src/aven.cc b/src/aven.cc
index 47c01188..45a62244 100644
--- a/src/aven.cc
+++ b/src/aven.cc
@@ -184,10 +184,6 @@ int main(int argc, char **argv)
     // work to set it here.  GTK2 doesn't support Wayland, so doesn't need
     // this.
     setenv("GDK_BACKEND", "x11", 1);
-    // FIXME: The OpenGL code needs work before scaling on hidpi displays will
-    // work usefully, so for now disable such scaling (which simulates how
-    // things are when using GTK2).
-    setenv("GDK_SCALE", "1", 1);
 #endif
 #ifdef __WXMAC__
     // MacOS passes a magic -psn_XXXX command line argument in argv[1] which
diff --git a/src/gla-gl.cc b/src/gla-gl.cc
index 643a1ab8..4bb0aaf7 100644
--- a/src/gla-gl.cc
+++ b/src/gla-gl.cc
@@ -434,6 +434,8 @@ void GLACanvas::FirstShow()
 {
     // Update our record of the client area size and centre.
     GetClientSize(&x_size, &y_size);
+    x_size *= GetContentScaleFactor();
+    y_size *= GetContentScaleFactor();
     if (x_size < 1) x_size = 1;
     if (y_size < 1) y_size = 1;
 
@@ -646,8 +648,8 @@ void GLACanvas::OnSize(wxSizeEvent & event)
 
 	// The width and height go to zero when the panel is dragged right
 	// across so we clamp them to be at least 1 to avoid problems.
-	x_size = size.GetWidth();
-	y_size = size.GetHeight();
+	x_size = size.GetWidth() * GetContentScaleFactor();
+	y_size = size.GetHeight() * GetContentScaleFactor();
 	if (x_size < 1) x_size = 1;
 	if (y_size < 1) y_size = 1;
     }

This appears to make the OpenGL pane use the full space available when
tested with a normal display and GDK_SCALE=2, but I'm not confident that
setting GDK_SCALE would fully emulate the situation when OpenGL is in the
mix, which is why I think this is best worked on by someone with actual
hardware (or is there anyone in/near Wellington who can lend me a hidpi
screen for a weekend?)

This patch probably also still leaves you with tiny text and indicators
inside the OpenGL, in which case those need scaling up to match.

The indicators are drawn using graphics primitives so scaling them up
should mostly be a matter of inserting the scale factor at appropriate
places.

The text is drawn with glBitmap() currently, which I think doesn't allow
scaling.  It'd also look a bit nicer not to just scale up the bitmaps
but instead use something that's actually a higher resolution.  Is hidpi
actually always 2x currently?  If so we could probably ship a
pre-calculated bitmap font that's suitable for 2x for now.

Or maybe there's a suitable font library with OpenGL support.  The key
things are it needs to render text fast enough to draw a lot of labels
while still animating smoothly, and to support full Unicode.  I didn't
find a suitable existing option when I wrote the current code, but
that was a decade ago.

Cheers,
    Olly