Xpra: Ticket #1933: hidpi awareness for macos
See also Automatically scale windows? - similar problem for wayland vs x11
Tue, 11 Sep 2018 06:32:37 GMT - Antoine Martin: status, description changed
- status changed from new to assigned
- description modified (diff)
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.
Sun, 11 Aug 2019 05:11:45 GMT - Antoine Martin: milestone changed
- milestone changed from future to 4.0
It may be possible to enable HIDPI mode for testing - though this may require newer versions of macos:
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
Sat, 21 Sep 2019 19:36:10 GMT - Antoine Martin:
Thu, 05 Mar 2020 10:49:00 GMT - Antoine Martin: milestone changed
- milestone changed from 4.0 to 4.1
Thu, 24 Sep 2020 15:40:38 GMT - Antoine Martin: attachment set
- attachment set to osx-highdpi.png
problem with best resolution
Thu, 24 Sep 2020 15:43:36 GMT - 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.
Thu, 24 Sep 2020 19:15:04 GMT - 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.
Thu, 24 Sep 2020 20:24:54 GMT - 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.
Fri, 25 Sep 2020 06:57:35 GMT - 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?
Fri, 25 Sep 2020 10:43:13 GMT - 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.
Wed, 30 Sep 2020 10:13:29 GMT - 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...
Wed, 30 Sep 2020 10:45:37 GMT - 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.
Mon, 28 Dec 2020 15:11:55 GMT - Antoine Martin: milestone changed
- milestone changed from 4.1 to 4.2
Sat, 23 Jan 2021 05:37:41 GMT - migration script:
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1933