Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOS: Catalina: Actual application occupies a quarter of the window #794

Closed
el-dee opened this issue Nov 27, 2019 · 12 comments
Closed

MacOS: Catalina: Actual application occupies a quarter of the window #794

el-dee opened this issue Nov 27, 2019 · 12 comments
Labels
Milestone

Comments

@el-dee
Copy link
Contributor

@el-dee el-dee commented Nov 27, 2019

As seen on the screenshot below, Panda application on Catalina are confined to the lower left quarter of the window. I guess this is related to the HiDPI scaling of the Retina monitor and that somehow it's no longer applied properly.

Screenshot

@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Nov 28, 2019

Problem is linked with the default value of setWantsBestResolutionOpenGLSurface which seems to have been changed in Catalina, the default mode is HiDPI ON now. Godot and SDL had the same problem, their fix are:

SDL : https://hg.libsdl.org/SDL/rev/46b094f7d20e

Godot : godotengine/godot#32809

el-dee added a commit to el-dee/panda3d that referenced this issue Nov 28, 2019
el-dee added a commit to el-dee/panda3d that referenced this issue Nov 28, 2019
@rdb

This comment has been minimized.

Copy link
Member

@rdb rdb commented Nov 28, 2019

Could it be that Cocoa is giving the OpenGL window a smaller window size than is actually in existence? In other words, would it be fixed if we doubled the window size that Cocoa reports?

@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Nov 28, 2019

EDIT: scaling was confusing, I rewrote that part...

Not exactly, from what I learned, until Catalina, an app had to specify that it supports scaling on the OpenGL frame buffer (backing surface in the Apple lingo). If not activated (the default mode), a pixel in the frame buffer is rendered as a pixel on the screen and when the screen scaling factor is greater than one, the rendered window is scaled accordingly).
If scaling is activated, the frame buffer is magnified or scaled down according to the scaling factor and the application has to manage the scaling factor and convert the frame buffer units to the screen units, see https://developer.apple.com/documentation/appkit/nsview/1414938-wantsbestresolutionopenglsurface

From Catalina onwards, OpenGL app have the scaling automatically activated, even if the app does not support it. Sadly, there is no information from Apple about this change, but you see many OpenGL based applications having that change performed the last months due to Catalina.

@rdb rdb added bug macos labels Nov 29, 2019
@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 3, 2019

Even with the fix, the problem occurs if you switch your application to fullscreen. Worse, if you switch back to windowed mode, the window is moved out of the screen and so no longer reachable, though still visible if you ask the desktop to show all the windows of the app.

I also tested a panda application not compiled on Catalina; in windowed mode there is no problem even without the workaround, but the fullscreen issue is present too.

@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 3, 2019

The problem is that in

find_display_mode(int width, int height) {
only the display size is used to find the new mode, the new mode should also have the same scaling factor as the current view (or we have to recreate a new view and switch over it, or something like that)

@rdb rdb closed this in f72c72b Dec 8, 2019
@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 8, 2019

Don't close this one yet, I will have soon a patch to fix the issue with the fullscreen scale.

@rdb rdb reopened this Dec 8, 2019
@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 11, 2019

I'm struggling to have an identical behaviour between Panda3D on Mojave or older and Catalina...

On Mojave (or older), the underlying graphic engine does the scaling and coordinate adaptation for the application if it does not support HiDPI. If I start the application, on a retina screen, there is a 2x scaling factor automatically applied (a 800x600 window is rendered on a 1600x1200 rect on screen). If I switch to fullscreen in app using WindowProperties, the app with the current code switch to a non scaled mode but the view coordinates are updated by the underlying graphic engine. This is the first weirdness.

On Catalina, the coordinate update is no longer done by the graphic engine (or at least I can't find anywhere how to trigger it), so my patch to avoid scaling or cropping is to select the display mode with the required dimensions and with the same scaling factor as the current view. So, contrary to Mojave, the display mode for fullscreen will also be upscaled if the original window was already upscaled, and if the selected display mode dimension does not exist with the scaling factor the app had at startup the fullscreen can not be activated.

If the difference in behaviour is acceptable I will create a PR with the patch.

@rdb

This comment has been minimized.

Copy link
Member

@rdb rdb commented Dec 11, 2019

I wonder, should we perhaps be using [_view enterFullscreenMode] instead of the current CGLSetFullScreenOnDisplay-based approach on Catalina? I believe that the current method is deprecated (but then, all of OpenGL is deprecated, so I don't know how much that actually means).

@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 11, 2019

Many GC methods that Panda uses are also deprecated so I would say that in Panda 1.11 a good clean up will be needed, especially following the end of support of 10.6 SDK

I can give [_view enterFullscreenMode] a try, but it might be a non trivial modification. Another possibility is to use CGContextScaleCTM to apply the scaling on the context and emulate Mojave behaviour, though I'm not sure if it works with non-layered context...

@rdb

This comment has been minimized.

Copy link
Member

@rdb rdb commented Dec 11, 2019

Unfortunately cleaning out all deprecated things means abandoning OpenGL and adopting Metal, which is not at all a trivial endeavour, so we're stuck with picking and choosing our deprecated APIs for the forseeable future.

I appreciate that you're looking into this! If it turns out to be non-trivial, certainly your proposed fix sounds like it would still be better than having the game cover only a quarter of the window in fullscreen mode.

@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 12, 2019

I did a quick test with enterFullScreenMode, first it does not seem to allow to specify the fullscreen resolution (or it is hidden in one of the sub options) and there are still scaling issues (though they might be resolved by specifying the drawable size of the attached layer of the view, but this is not really well documented).
There is another problem, using this method further keyboard and mouse events are lost once I click or press a key. So this does not look good for a quick fix.

I will try and test CGContextScaleCTM this week-end.

@el-dee

This comment has been minimized.

Copy link
Contributor Author

@el-dee el-dee commented Dec 14, 2019

Well, CGContextScaleCTM is a dead end, I tried again with enterFullScreenMode bu I could not fix the problem with the input event (I made sure that the view was still the first responder, tried also with makeKeyAndOrderFront, ... but to no avail).

Panda3D does a lot of the view and event management internally, so it might conflict with what the higher level API from apple does (though it's pure guesswork).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.