RetroArch XMB performance on Raspberry Pi 1/2/Zero
-
Totally understandable, but the xmb driver is the upstream default now, so rgui is not guaranteed to be well maintained in future. There are also other arguments in xmb's favour regarding accessibility (in the old thread). Perhaps the unnecessary assets can be stripped down & xmb assets resized or recompressed in a custom repository to minimize the size. As it stands, the assets directory comes to 188MB, but that includes the .git repo. The xmb asset folder itself is just 49MB and presumably could be stripped even more.
Regardless, I'm still genuinely curious to know how it performs on the old Pi revisions no matter what the RetroPie developers ultimately decide.
Edit: upon checking, it seems that we only need 6MB of assets for the default Monochrome xmb icon theme. Seems more reasonable now...
-
Here's a way to download the required assets without fetching the entire repo:
svn export https://github.com/libretro/retroarch-assets/trunk/xmb/monochrome xmb/monochrome/
This will fetch just 6MB and leave no .git folder behind. It can be easily integrated into the source build process for retroarch and the assets can be packaged with the binary.
-
@psyke83
That sounds awesome and super reasonable in size.How would go about doing this via command line?
-
The actual assets are located in /opt/retropie/configs/all/retroarch/assets, but retroarch itself relies on a symlink to that location to be present in /opt/retropie/emulators/retroarch/. If the symlink is only created during full asset installation, the scripts would need to be changed so that the symlink is created by default.
It's a bit too complicated for users to do. I'll submit a patch for review (not to make xmb the default driver, but to install xmb assets by default so that xmb is usable without full assets). But the above technique would require subversion to be installed by default (2MB of packages).
Edit: I've submitted a PR here: https://github.com/RetroPie/RetroPie-Setup/pull/2007
-
Changing important defaults in RetroPie always causes a bit of a commotion. I am not for changing any defaults right now but will listen to user feedback after testing (eg on the rpi1). If upstream moves away from RGUI completely we would of course have to switch.
I actually prefer RGUI on RetroPie as we don't use it for launching etc, but just some settings/configuration. I would need to be sure if we do change, that I don't get hundreds of complaints from people :)
-
Yep, I'm definitely curious about performance on older models regardless of what you folks decide.
Another thing to note is that it's possible to disable the shader pipeline in xmb (i.e. disable the ribbon effect), so that could be a compromise to implement for older models if the performance still isn't up to scratch.
The next version of RetroArch will also support transparency when the shader pipeline is disabled or using a custom wallpaper (fixed in my patch I referenced earlier).
-
i think generally retropie users shouldn't really be using the retroarch GUI at all! i believe it's currently possible to disable certain menus so it might be worth us disabling all but the quick menu/core options, if that's possible. by default none of the other options save anyway, right? i think if we made it 'bullet proof' we could re-work some of our documentation.
but yeah, back on topic - i prefer the XMB but one consideration is CRT users - how does it appear at those extremely low (or strange) resolutions?
-
I like to use XMB on my Android devices (since we don't have a decent frontend on Android for free). On RetroPie I always stick with RGUI and am very happy.
But I'll make some tests with XMB on my raspi1 and give some feedback here.
-
@meleu said in RetroArch XMB performance on Raspberry Pi 1/2/Zero:
I like to use XMB on my Android devices (since we don't have a decent frontend on Android for free). On RetroPie I always stick with RGUI and am very happy.
But I'll make some tests with XMB on my raspi1 and give some feedback here.
Great, thank you. Please try with the shader pipeline disabled if performance is inadequate with the default ribbon/simplified ribbon pipeline.
I'm not going to push for xmb to be made the default, as people clearly have their own preferences and @BuZz has made his position clear, but I would love to see xmb usable in the default installation (after changing the menu driver manually). At the moment, people need to manually install the full assets (it's not entirely obvious why the menu has horrible black squares in place of icons or precisely how to install assets when you're not familiar with the retropie-setup menu). That was the intention of my recent PR to add the basic xmb icon theme assets (which adds perhaps 10MB in total to the size of the default installation). My PR was rejected but fingers crossed that @BuZz can implement something in a better way.
-
@dankcushions said in RetroArch XMB performance on Raspberry Pi 1/2/Zero:
i think generally retropie users shouldn't really be using the retroarch GUI at all! i believe it's currently possible to disable certain menus so it might be worth us disabling all but the quick menu/core options, if that's possible. by default none of the other options save anyway, right? i think if we made it 'bullet proof' we could re-work some of our documentation.
but yeah, back on topic - i prefer the XMB but one consideration is CRT users - how does it appear at those extremely low (or strange) resolutions?
I personally love the ability to pause content on the fly (and I can never remember the key combo to save vs load, so I prefer to do it manually). It's probably confusing for beginners that their menu configuration isn't saved by default, but RetroArch itself is not exactly childproof...
That's a good question re: fonts on CRT monitors but I know for sure it can be tweaked via the "xmb_scale_factor" configuration.
-
@psyke83 here's my feedback:
XMB runs pretty well on my raspi1 (overclocked to High).
More details:
- icon shadows [ON]
- shader pipeline [Ribbon (simplified)]: a really little bit of lag but perfectly acceptable.
- shader pipeline [Ribbon]: same as above.
- shader pipeline [OFF]: suprisingly same as above.
- shader pipeline [Simple Snow]: laggy. It's usable, but the lag bothers.
- shader pipeline [Snow]: same as above (laggy).
- shader pipeline [Bokeh]: same as above (laggy).
- icon shadows [OFF]
- shader pipeline [Ribbon (simplified)]: pretty smooth.
- shader pipeline [Ribbon]: same as above.
- shader pipeline [OFF]: same as above.
- shader pipeline [Simple Snow]: laggy. It's usable, but the lag bothers.
- shader pipeline [Snow]: same as above (laggy).
- shader pipeline [Bokeh]: same as above (laggy).
Conclusion
With Menu Shader Pipeline as Ribbon (simplified), Ribbon or OFF it runs well, independent if Icon Shadows Enable is ON, but if Icon Shadows Enable is OFF it's pretty smooth.
I emphasize, my raspi1 is overclocked to High (950MHz ARM, 250MHz core, 450MHz SDRAM, 6 overvolt).
- icon shadows [ON]
-
Thanks! The non-ribbon shaders aren't viable even on the RPi3, so that's not a big surprise.
What did surprise is that icon shadows only lag a bit. I'm guessing it's different because RetroArch's resolution is constrained to 640x480 on the RPi1, so the overhead is lower.
-
Update: @BuZz merged his redo of my PR that ensures xmb's icon assets are included in the default install, so in future releases you'll be able to manually switch to the xmb driver without having to install the full retroarch assets. Thanks!
I'm still curious if anyone can test xmb on a Pi 2 or Zero, as RetroPie doesn't limit the resolution to 640x480 on those devices... but I'm reasonably confident that performance will be satisfactory.
-
RetroArch 1.6.1 is available when you update packages via the latest RetroPie-Setup. This version has transparent xmb menus, so if that's a feature of the rgui menu driver you miss, check it out. I haven't noticed any performance differences on Raspberry Pi 3, but your mileage may vary.
-
RetroArch 1.6.4 have been just released and I noticed one line in the annoucement that reminded me this thread:
GUI: You can turn on/off ‘Horizontal Animation’ now for the XMB menu. Turning animations off can result in a performance boost.
Good news, huh? :)
-
@meleu said in RetroArch XMB performance on Raspberry Pi 1/2/Zero:
RetroArch 1.6.4 have been just released and I noticed one line in the annoucement that reminded me this thread:
GUI: You can turn on/off ‘Horizontal Animation’ now for the XMB menu. Turning animations off can result in a performance boost.
Good news, huh? :)
Yes. I still use and prefer the xmb driver, but I'm less inclined to think it's suitable as a default due to the fact that it breaks RetroArch if you're using the dispmanx driver. I have no use for dispmanx, but that would be a headache for anybody that does.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.