Opened 3 years ago
Last modified 3 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: |
Description (last modified by )
See also Automatically scale windows? - similar problem for wayland vs x11
Attachments (1)
Change History (14)
comment:1 Changed 3 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 21 months ago by
Milestone: | future → 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
comment:3 Changed 19 months ago by
comment:4 Changed 14 months ago by
Milestone: | 4.0 → 4.1 |
---|
comment:5 Changed 7 months ago by
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.
comment:6 Changed 7 months ago by
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.
comment:7 Changed 7 months ago by
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.
comment:8 Changed 7 months ago by
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 7 months ago by
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 7 months ago by
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 7 months ago by
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 4 months ago by
Milestone: | 4.1 → 4.2 |
---|
comment:13 Changed 3 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1933
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.