hidpi awareness for macos

[Antoine Martin]

See ​Is HiDPI possible?

See also ​Automatically scale windows? - similar problem for wayland vs x11

​Optimizing for High Resolution

[Antoine Martin]

It might be possible to paint at higher resolution through opengl.
In which case the fix would simply be to scale window positions and dimensions when dealing with GTK, but keep the opengl window backing at the "native" resolution.

[Antoine Martin]

It may be possible to enable HIDPI mode for testing - though this may require newer versions of macos:

• ​How to Enable HiDPI Mode in macOS
• ​hidpi_osx: Enable HiDPI mode on OS X

The API to call with opengl seems to be ​Optimizing OpenGL for High Resolution: setWantsBestResolutionOpenGLSurface.
The main difficulty with this is that we would need to use double screen dimensions (or whatever ratio is used) when connecting to the server but then downscale the coordinates for all window operations except for opengl painting.

Another difficulty is to do with how we obtain the opengl context: we initialize it without the window (which may be the cause of some problems: r23441 / #2372), so by the time we have the NSView object it may be too late to call setWantsBestResolutionOpenGLSurface. Not sure how we would go about selecting pixel format attributes if we did it that way - not that we currently support high bit depth anyway..

Example code: ​PyOpenGL on a Macbook retina display

[Antoine Martin]

See also #2410, #2500.

[Antoine Martin]

problem with best resolution

[Antoine Martin]

Received by email:

--- src/xpra/platform/darwin/gl_context.py (revision 27534)
+++ src/xpra/platform/darwin/gl_context.py (working copy)
@@ -150,6 +150,7 @@
         if not self.window_context:
             self.nsview_ptr = nsview_ptr
             nsview = objc.objc_object(c_void_p=nsview_ptr)
+            nsview.setWantsBestResolutionOpenGLSurface_(True)
             log("get_paint_context(%s) nsview(%#x)=%s", gdk_window, nsview_ptr, nsview)
             if self.alpha and enable_transparency:
                 self.gl_context.setValues_forParameter_([0], NSOpenGLCPSurfaceOpacity)

I managed to enable proper hidpi rendering resolution. However the scale is off and the view is too low. I tried to correct it by changing glViewport and moving the view with glTranslatef, but the view is clamped to the bottom left corner.

It's not clear to me what type of session it is connected to.
But I guess that we need to adjust the scaling to match the actual window dpi.

[hawski]

Hi,

That's my report above in ticket:1933#comment:5. I'm not sure what you mean by type of session, but it is MacOS Mojave shadow to Void Linux running Xfce.

I think what would be right is for the window to be smaller.

[hawski]

Oh, indeed it's a scaling issue. The window is just bigger then my screen, so it's not offset. It's probably more on to the view or the window, however, because changing the viewport does not affect this.

[Antoine Martin]

Oh, indeed it's a scaling issue

We need to know the actual multiplier to use, preferably before creating the window.
Any idea how to do that?

[hawski]

The common way, that is not exactly correct, but still an improvement, would be to use: [[NSScreen mainScreen] backingScaleFactor]

The problem is, that one can have multiple screens attached with varying scale factor.

This article suggest reacting to the changes: ​http://supermegaultragroovy.com/2012/10/24/coding-for-high-resolution-on-os-x-read-this/ but I don't know if it is applicable to Xpra, as it assumes layer-backed and/or layer-hosting view. I don't know if it makes sense.

I also wonder how newer GDK handles it as at least on the master branch it calls setWantsBestResolutionOpenGLSurface in its internals: ​https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/macos/gdkmacosglcontext.c#L121 This file got merged two months ago, so probably it's not relevant to Xpra as it is probably part of GTK4.

[Antoine Martin]

This article suggest reacting to the changes

That makes sense, but this may well require changes to the window geometry to adapt to the new scaling factor. And that's known to cause problems (resizing loops, etc).
I don't have the hardware to test either.
(so don't hold your breadth - this could take time)

.. probably it's not relevant to Xpra as it is probably part of GTK4

Correct. We can't use GTK for opengl anyway, as this would require a rewrite of the opengl window rendering code...

[hawski]

I scaled 2x render_size in init from xpra/client/gl/gl_window_backing_base.py Then it looks good on single display. I will check later how it works with backingScaleFactor, but it's good enough for me now.

I have massive lag on local network, but it is unrelated to my changes as far as I see, because the same lag is noticeable with --opengl=no.

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/1933