Problems with native UI (#4011)

[kd-11]

Metabug for tracking remaining bugs with https://github.com/RPCS3/rpcs3/pull/4011 Known issues:

• [x] vulkan can assert randomly when rendering a dialog
• [x] only ASCII text is supported
• [x] code quality: refactoring of some methods into separate helpers is sorely needed to remove hacks in rsx core
• [x] some games do not initialize the controllers at startup making input not work

[toccata10]

You could add that on linux, with radv (r9 fury, Archlinux), instead of messages, I just get black screen with high fps. It's not frozen: if I press the correct button on the pad, it resumes the game. OpenGl has a correct behaviour, so it's just problematic with Vulkan.

[kd-11]

So far its been noted only on arch and manjaro, so I'm thinking something else is interferig. I have the same vulkan library version, same gpu and even driver version, but manjaro vs ubuntu. Works on ubuntu, nothing on majaro. Investigations are ongoing.

[twdarkeh]

Any reasonable way to get saves to sort by most recent?

[kd-11]

No

[marsselluo]

When launch a game directly into fullscreen mode, the image is cropped at the upper left of the screen. It only happens in vulkan. Exiting the fullscreen and enter again fix it. Sorry for my english. RPCS3.log.gz

[micaelis72]

Folks, I found a little bug. When installing Atellier Escha & Logy, using the native interface, the instalation starts before finding a controller, breaking the installation giving an error in the dialog -3. If it's needed, I can provide logs of this! Let me know if it's necessary.

[StarWolf3000]

In addition to greentop's comment in #4011 regarding HDN, it also freezes with OpenGL (only have OpenGL as renderer) upon trying to call the new "Save file" UI, while "Load" works without problems.

[Asinin3]

@marsselluo That issue has existed for awhile, not related to this PR.

[kd-11]

@marsselluo Theres no proper way around that right now, it needs reworking how fullscreen start works. Window should go into fullscreen before the renderer starts like is done for games but it does not. Thats another issue altogether.

[marsselluo]

@Kd11 @Asinin3 I thought it was related because if I deactivated the Native UI on the settings the problem doesn't appear. Anyway thanks for the answer.

[kd-11]

https://github.com/RPCS3/rpcs3/pull/4093 Should fix the VkGSRender assert.

@marsselluo Its indirectly related. When that dialog pops up the renderer is just initializing and does not have all the information ready. It will be improved later on but just reset fullscreen after loading is complete for now.

[greentop]

4093 Fixes the the game saving issue in Hyperdimension Neptunia (BLUS30701) in Vulkan. All games however are segfaulting in Ubuntu 16.04 upon loading a game save if when using the OpenGL renderer in the new UI. GDB was able to grab a backtrace (Line 155559).

The Use native user interface: false option under #4093 is also crashing out RPCS3 if using the OpenGL renderer (RPCS3_QT_UI_crash.log.gz).

RPCS3_QT_UI_crash.log.gz RPCS3_4093_OpenGL_Segfault.log.gz gdb-rpcs3_4093.txt.gz

Edit:

PR #4127 corrects the Use native user interface: false crash.

[kd-11]

@greentop OpenGL crash is fixed. I'm surprised it went unnoticed for this long.

[Kadaban]

Two minor problems I've found with the new native UI:

1. Loading Shaders is a LOT slower with the native UI. Loading speed seems to be tied to emulation/ingame/rendering FPS. For example loading about 800 shaders in ni no kuni with the old versions loads the shaders in about 3 seconds, with the native UI it's a lot more than 10.

2. Opening the save or load dialog seems to hang rpcs3 for a good 2-3 seconds before actually rendering the menu. No problems after this though.

[13xforever]

It wasn't stated explicitly, but the problem with Native UI on Arch is not AMD-specific. I get black screen with proprietary nvidia drivers as well.

[Asinin3]

@Kadaban Even without the native UI if you load shaders then close the game and load them again the second time is generally more than half the speed. I'm guessing this is because it's still sitting in ram/vram. I'm not so sure it is actually slower at loading shaders in.

[Kadaban]

@Asinin3 I know about caching, but that's not the problem here. Even with the emulator loaded into ram the loading is still objectively slower with the new UI than it was with the simple loading bar we had before.

[raveskirza]

@Kadaban You can disable the Native UI under settings--> Emulator and verify

[Kadaban]

Tested against version 0.0.4-6355 with 875 filters loaded in from cache. Game is Ni No Kuni. Times are in seconds. Native UI disabled: 5:36 Native UI enabled: 16:07

My guess is that the native UI tries to render each and every increment of the "Loading pipeline object x of y" dialog when loading the shaders instead of loading the shaders as fast as possible simply ignoring some updates.

Btw: the same thing happened with cemu in one of the older updates. It hit loading performance a lot harder though before they finally "unsynced" refresh rate/fps from the shader loading indicator.

EDIT: Just redid the test with version 0.0.4-6368, just in case someone "complains" about me having an older version, and the loading times didn't change noticeably.

[toccata10]

Battle Fantasia [NPUB30126] is now black screen even on Vulkan (excepted for the intro video). I reported an issue here: #2987 but it worked on Vulkan, while Ogl gave only a black screen. I tracked down the commit: it's the #4011 which broke rendering on Vulkan too. Tested on win10 with nvidia card. Same behaviour with rpcs3-v0.0.5-6647 on archlinux with r9 fury (mesa 18.0). I join my renderdoc files. The ok one was captured on rpcs3-v0.0.4-2018-01-17-34c49c77_win64 The other on rpcs3-v0.0.5-6648-ea82b732_win64 No rendering (=black) on Ogl since quite some time, so only 1 renderdoc capture.

bf-black-Ogl.zip bf-black-vk.zip BF-ok-vk.zip

[Megamouse]

Just wanted to remind you of the funny 's' glitch in combination with the debug overlay during initial shader compilation.

[Megamouse]

I observed 2 behaviours regarding the aspect ratio:

1. The Native UI doesn't handle resizing the gsframe to a different ratio. Meaning: The game will still be 16:9, but the UI will fill the whole Frame.

2. Changing the Aspect Ratio of the gsframe while we precompile shaders will result in the game also filling out the whole frame until I resize the frame later once more.

[alanliu02]

Please add a feature to support other language instead of ASCII only. Many save files of JP games dont have ASCII text,Its hard to recognize some of the saves.

[Johndeep]

I have trouble to categorize the problem correctly, but if it is about the native UI issues, then I have some to report, coming from Linux Debian Testing. I normally have a FullHD screen (1080p) but even if I have the Default Resolution "1280x720 (Recommended)" option enabled, in both Vulkan and OpenGL mode, the window always scales double the configured size. I suspect that qt has issues with scaling? In the same way, the GUI is totally overscaled, but the font seems to be unaffected.

I do hope that I can fix this myself (since it might be an issue caused by xfce), but I find it very odd that the gui elements are double the size while the fonts are unscaled and thus small. This might have something to do with that qt has trouble with correct theming since 5.6+, I think.

[kd-11]

By native UI we mean ps3-native UI. The ui elements provided inside the game window.

[kd-11]

Multi-language support fixed with https://github.com/RPCS3/rpcs3/pull/7551. This closes the ticket.