xpra icon
Bug tracker and wiki

Opened 2 years ago

Last modified 4 weeks ago

#1933 assigned task

hidpi awareness for macos

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

Attachments (1)

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

Download all attachments as: .zip

Change History (12)

comment:1 Changed 2 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 15 months 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 13 months ago by Antoine Martin

See also #2410, #2500.

Last edited 11 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 8 months ago by Antoine Martin

Milestone: 4.04.1

Changed 5 weeks ago by Antoine Martin

Attachment: osx-highdpi.png added

problem with best resolution

comment:5 Changed 5 weeks 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 5 weeks ago by 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.

Last edited 5 weeks ago by hawski (previous) (diff)

comment:7 Changed 5 weeks 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 5 weeks ago by hawski (previous) (diff)

comment:8 Changed 5 weeks 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 5 weeks 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 4 weeks 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 4 weeks 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.

Note: See TracTickets for help on using tickets.