xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 4 years ago

Last modified 16 months ago

#1933 assigned task

hidpi awareness for macos

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 4.2
Component: platforms Version: 2.3.x
Keywords: Cc:

Attachments (1)

osx-highdpi.png (568.2 KB) - added by Antoine Martin 20 months ago.
problem with best resolution

Download all attachments as: .zip

Change History (14)

comment:1 Changed 4 years ago by Antoine Martin

Description: modified (diff)
Status: newassigned

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.

comment:2 Changed 3 years ago by Antoine Martin

Milestone: future4.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

comment:3 Changed 3 years ago by Antoine Martin

See also #2410, #2500.

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:4 Changed 2 years ago by Antoine Martin

Milestone: 4.04.1

Changed 20 months ago by Antoine Martin

Attachment: osx-highdpi.png added

problem with best resolution

comment:5 Changed 20 months ago by 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.
problem with best resolution

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.

comment:6 Changed 20 months ago by hawski


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.

Last edited 20 months ago by hawski (previous) (diff)

comment:7 Changed 20 months ago by 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.

Last edited 20 months ago by hawski (previous) (diff)

comment:8 Changed 20 months ago by 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?

comment:9 Changed 20 months ago by 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.

comment:10 Changed 20 months ago by 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...

comment:11 Changed 20 months ago by 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.

comment:12 Changed 17 months ago by Antoine Martin

Milestone: 4.14.2

comment:13 Changed 16 months ago by migration script

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

Note: See TracTickets for help on using tickets.