Fix render resolution at different UI scales #514
Loading…
Reference in a new issue
No description provided.
Delete branch "scalingfix"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I do not have a HiDPI/retina display at my disposal so I'd appreciate if people who do can test this.
Disregard this for now. I wasn't paying close enough attention. Cemu already uses currentExtent when it is defined.
Vulkan on wayland apparently returns 0xFFFFFFFF for the currentExtent. Not sure if that's also the case with XWayland. If it does though it would explain this behaviour. It's unnoticeable when using 1x scaling because cemu has a fallback to wxWidgets window coordinates, but when using scaling those values are no longer in physical pixels so the swapchain extent doesn't match the window size and you get graphical issues like this:
using the physical pixel size should fix this. MacOS apparently also doesn't render at native resolution but this could be a different issue.
I have created a pull request #516 that fixes high DPI scaling on macOS which works quite well. (I wasn't aware of your changes)
I suggest you compare the changes and assess whether your macOS change is still necessary or if my implementation can be improved.
I have tested these changes on a Retina Mac, and they work well. However, there is also the same issue, that after a DPI change only the Metal backend resolution changes. So if the DPI changes from high DPI to normal, the view will only show the cut off top left area until the window is resized. I believe this is because
MainWindow::OnSizeEventis not triggered on DPI change, sophys_width/phys_heightstay unchanged even though they should change.@greybaron I'm afraid that isn't the problem. According to this wxWidgets forum post DPI changes across different monitors is not supported as of 2019. So I think to get DPI updates across monitors working we need to wait for wxWidgets to support it.
Sorry. I missed this part. You're probably correct then!
@greybaron I've added a DPIChanged event handler. Give the latest commit a try!
@goeiecool9999 your branch up to 8436140 works perfectly fine and solves the issue. Just as a sidenote, Cemu crashes on macOS if compiled with the merged commits from main.
I can't reproduce it myself so it might be DPI related. Crash log would be much appreciated.
I have tried some more, this is really weird:
Error: signal 11:signal 6.log
signal 11.log
And it doesn't crash on the latest commit on the main branch?
correct.
I found a program that allowed me to raise the DPI of my main display to be hi DPI. I was dragging cemu between my monitors and watched the scaling change on the latest commit. Very confused about these crashes you're experiencing. They seem to come out of nowhere...
@goeiecool9999 Just to make sure:
THIS is my binary which is (almost always) crashing. Can you confirm that this does not crash for you?
Edit in case this isn't clear: Cemu crashes on game launch, the DPI does not matter
Okay strangely enough your binary runs fine for me. This is a bit puzzling.
I have a branch here (scalingfixcrashfixtest) that merges #525 with this PR. I hope it relieves the crashing issue. The changes made in #502 make cemu interact with vulkan in a non-standard way and it may be causing issues with MoltenVK. It's a long shot but it might work.
I've done some testing on my intel mac.
The main branch works fine for me. "fixchainimagecount" works fine.
The "scalingfix" branch and "scalingfixcrashfixtest" branch crashes instant when a game tries to load, without even a splash screen, with
"libc++abi: terminating with uncaught exception of type std::length_error: allocator::allocate(size_t n) 'n' exceeds maximum supported size
Error: signal 6:".
log.txt
console.txt
From what I can tell merging origin/main into scalingfix was the cause, the latest commit at the time of writing. Separately, both work and scalingfix does also produce the correct physical resolution. Tested by reverting to the previous commit
Up till now I experienced the crash once. I have tried everything I could think of. I'm not sure how to continue looking from here. I know this may be a big ask but it could be helpful if someone rebased this branch onto main and then bisected the commit that causes the crash.
I'm pretty inexperienced with git, so I'll tell you step by step what I did...
VulkanCanvas.cpp(I accepted incoming like you)The reason i'm confused is that I still don't know which commit to upstream broke your commit
ab0791d. However I guess that is why there was a merge conflict. Let me know if I can try anything elseI also tried to combine the conflicts by essentially reapplying
47f829e265Thank you very much
I don't believe I did accept incoming. I applied both the parent->GetClientSize() change and the wxNO_FULL_REPAINT_ON_RESIZE change in the merge commit.
However that doesn't matter. You're right this is confusing.
The obvious suspect is wxNO_FULL_REPAINT_ON_RESIZE. It appears that that flag combined with the changes in scalingfix is somehow causing the crash but that seems highly unlikely and we just learned that not using it doesn't fix the problem either. So what's going on here?
One last thing we could try is to rebase main onto scalingfix with something like
and then bisect again.
Then you're bisecting upstream changes applied after scaling fix instead of before. I really hope this will reveal something otherwise I'm tempted to chalk this up to undefined behaviour or something.
Now when rebasing, should I go with HEAD or incoming?
the commit should have both parent->GetClientSize() and wxNO_FULL_REPAINT_ON_RESIZE. I'm not sure what the vscode "accept both changes" option does but that sounds most like what you want. It probably lets you manually edit the file if it can't do it automatically.
Finally found it 🎉
This is the issue:
Reverting the change fixes the crashing.
Great! I'm still not sure why that change is causing a crash but at least that's something I can work with!
Let me know if the latest version crashes or not. I think it should be fixed!
Still crashes, same logs
Very surprised by that. I thought for sure that was it.
I was rushing to conclusions. I thought I found a bug but I didn't.
I'm just throwing stuff against the wall at this point but does this change anything?
Looking it at it some more it probably doesn't. I'm really out of ideas.
still crashing
I guess one thing we should try is to run with the
MTL_DEBUG_LAYER=1environment variable and see if it outputs anything extra before the crash. And if it doesn't maybe we should also try to trigger the crash with vulkan validation layers. Although I haven't gotten them to work on macOS so it might be a bit tricky.I have a feeling that imgui doesn't like rendering to the 40x40 image, and I think that this change should prevent an image like that from being created. Please let me know if it works.
I can confirm the crash is fixed. Thank you for your hard work!
Out of curiosity, did you find out why the crash never occurred on your machine?
Awesome!
I have no idea. I did notice that my log never lists the tiny resolutions, even while using hi-DPI resolutions. That's probably why it doesn't crash for me. As to why it doesn't use the tiny resolutions is anyone's guess. I'm not on official apple hardware and use an older macOS version so it could be a lot of different things.
UI seems to change scale from hiDPI to regular DPI when moved between screens in macOS but I don't think that's a result of this patch.
IIRC per-monitor scaling is not supported on linux so I'd say displaying the right resolution and filling the screen at a different scale is good enough for now.
Then there's windows which from what I read here would require a lot of work to get scaling working. Though users who are setting the DPI override in the executable properties might still benefit from this change. UI will probably be blurry but the game might be the right resolution.
I'm renaming the PR once again because calling it DPI awareness seems like an overstatement.
I've just updated to 2.0-19 recently and I'm still having this issue, Moved from a 1080p monitor to a 4k TV and the UI and game is rendered at half res.