xenia
xenia copied to clipboard
xenia-project
Investigate New UI
We need a proper GUI in Xenia (that isn't ImGUI).
Qt
- [ ] Qt HID Backend (controller and keyboard, or just one of the two per?)
- [x] Initialize Vulkan backend from pre-created Qt resources, instead of vice versa
- [x] Make the Vulkan backend swap between frontbuffer and backbuffer
- Synchronization? The GPU will always lag behind the CPU, so shouldn't we lock the current backbuffer?
- [x] Make the Vulkan backend swap between frontbuffer and backbuffer
- Figure out how to pipe Qt Windows through existing code
- [ ] Hook up profiler to Qt window
- [ ] Abstract MicroprofileDrawer, Qt can subclass it.
- [ ] Direct Qt window events into various Profiler callbacks.
- [ ] XAM UI dialogs
- [ ] Hook up profiler to Qt window
Other possible candidates:
Web-based
- Chromium Embedded Framework (CEF)
- Worried about memory consumption - chrome is a resource hog!
- Mozilla Gecko (is embedding actively supported?)
If CEF is considered then we could possibly consider electron too. It's also a resource hog because chrome but as there are so many people with experience developing for electron it could lead to more contributors creating a very detailed and impressive looking UI. I'm not sure how easy it would be to combine electron with the native vulkan stuff though (which is why i'm guessing you suggested CEF over electron)
While Electron is nice, it's a framework/host for using CEF and other stuff. Not sure how well that would fit into the Xenia picture.
Mozilla Gecko (is embedding actively supported?)
It looks to be kinda difficult/not officially supported. XULRunner used to be a thing but it seems like they dropped support for it a while ago. The best info I can find about embedding Gecko is this blog post and this project which seems to wrap Electron around Gecko.
Qt (LGPL; iffy if we can statically link to this)
Seems fine, the part of the LGPL that makes people wary of static linking is section 4. Section 4 prevents proprietary applications from locking users to the specific version of a (LGPL) library that was statically linked by the application.
If you choose to statically link or otherwise combine your program with an LGPLv3’d work via mechanisms other than a shared library, you may choose your own license for the work provided the license terms limitations for user modification, reverse engineering and debugging are met, and given that the LGPL’d components are still governed by LGPL’s terms. You must offer or provide CCS for the LGPL’d components. The source code material provided must be sufficient to regenerate the combined work with a user-modified version of the LGPL’d components.
Chromium Embedded Framework (CEF)
- Worried about memory consumption - chrome is a resource hog!
Hi, look the others emulators dolphin or rps3, your teams moved the projects to qt for more speed and easing to programming interface to hi-dpi. I look that sooner or later professional projects move to qt and multi-platforms awesome works. Choosing others GUI, this project loses much time with bugs and hacks to include new features. On CEF, I would not recommend for this situation. This is my thinking, do not be nervous about it.
Well, xenia isn't dolphin, nor is it rps3. I'm quite intrigued about a web-based gui, so I look forward to seeing what comes of it. I won't disagree that Qt seems to be the way to go for everything nowadays, though.
Another interesting alternative is we could have a CEF frontend, and the emulator itself is ran separately to deal with the resource hog issue.
Of course, that could also be a waste of effort.
On Feb 23, 2018 10:05 PM, "Joshua Staska" [email protected] wrote:
Well, xenia isn't dolphin, nor is it rps3. I'm quite intrigued about a web-based gui, so I look forward to seeing what comes of it. I won't disagree that Qt seems to be the way to go for everything nowadays, though.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/benvanik/xenia/issues/1088#issuecomment-368197851, or mute the thread https://github.com/notifications/unsubscribe-auth/ACSoQfEI9au6P52CKgkUdXjPqXHWxbYfks5tX4qUgaJpZM4SPjMd .
Well, xenia isn't dolphin, nor is it rps3.
Yes, xenia is not a dolphin, nor is it rps3, never said it was, said about them as use examples that changed to qt after hundreds of strange errors with different screens, and with that write 9x more code to do the same thing in the new GUI, so I think the GUI should have all the necessary functions for a good design, be quick and without strange errors. And good documentation for the designer.
just add a couple of functions to the interface and do not change anything (for example, the ability to select User Language for multilingual games) :D
@rafahrpl I´m with you, qt seems the more reliable interface since it´s used by Dolphin, Rpcs3, Citra, Yuzu, etc. I have no programming skills but if all these emulators use qt there must be a reason for it ¿?
@Parovozik Oh man... my kingdom for the ability to choose other languages for multilingual games... xD
The reason it we're interested in something like CEF is that it would enable us to have fluid in-window rendered UIs that we could also easily adapt to controller compatible (much like official 360 UI is rendered over games).
Something like Qt would be for 'out of game' UI, ie menus, new window dialogs for options, etc.
It seems Qt supports vulkan in the latest release http://blog.qt.io/blog/2017/06/06/vulkan-support-qt-5-10-part-1/ I wonder if it would be possible to render the game to a Qt vulkan window which can also show Qt controls over the top. P.S I know absolutely nothing about vulkan or graphics development this is probably a laughable idea to those who do
Qt may actually be worth looking into - turns out dynamic linking to it is not a requirement (rather a legend); see here.
Okay - so if we want to use Qt, we need to have prebuilt libraries for it. Building Qt alongside Xenia is not an option.
Building Qt alongside Xenia is not an option.
And why is that? Did you see my post above?
@slx7R4GDZM Qt is way too big to compile with Xenia, not because of licensing issues.
From my (extremely limited) experience with Qt, I've found it really hard to work with Qt widgets, but much easier to work with QtQuickControls. quick is still in its infancy though so it's very possible it's not suitable for our use case
One or two weeks ago, dolphin moved his main build to Qt, maybe some of the devs can help us with xenia.
https://es.dolphin-emu.org/blog/2018/05/02/legend-dolphin-lens-between-worlds/
imgui is fine for an in-game overlay (which is what is currently used) but doesn't have nearly enough features for a proper desktop experience
kind of on topic but I created a proof of concept for what a Qt xenia might look like if it were borderless
This is obviously a (very) rough PoC but if I have the free time I will try and expand it to cover more areas such as a home screen, settings menus etc.
The purpose of a Qt UI, I think, is to get rid of that File menu in favor of a pretty-looking game list, and maybe also to remove the whole menu bar for a more immersive experience (like, CPU scale and profiler accessible only via F-keys shown in a help menu, or having to enable the menu somewhere in the settings, otherwise just display a window only containing the game). Options for aspect ratio (letterbox, maybe some key for reset, possibly borders like on the SNES Classic) would be nice also.
if i get any further with this then the menubar will absolutely be replaced, although i think it might be worth showing it while a game is running for easy access to options
@Triang3l Not trying to remove the file menu, just haven't implemented it yet. As of now, there's a fullscreen mode in Xenia but maybe we can have a borderless mode.
I forgot to link it here but I've been working on a Qt UI for xenia for quite a while now as you might know. You can track progress here https://github.com/Razzile/xenia/tree/qt-experimental/. I'll probably open a PR when all the original tasks of this issue are complete + support for the D3D12 renderer
Sciter; it is commercial but there is a free license. RmlUI; it is open-source, MIT licensed, and integrable with SDL2.
Sciter; it is commercial but there is a free license. RmlUI; it is open-source, MIT licensed, and integrable with SDL2.
RmlUI, aka Rocket, is extremely slow especially when it comes to tables like the game list.
One request for the new UI is that non-interactive popups, such as the achievement notification, should not be drawn in child windows on platforms where this matters, as that will result in OS composition being performed (on Android, composition always happens if I understand correctly, so this probably doesn't apply to it), which will make independent presentation impossible, preventing the use of variable frame rate, as well as increasing latency (and forcing a vsync wait that we don't request when borderless fullscreen is used, on Nvidia GeForce GTX 1070 on Windows 11 21H2). For popups, we may need some text rendering solution (such as FreeType for glyph rendering, and HarfBuzz for text shaping).