(Ozone) Fix blurry sidebar icons

[jdgleaver]

As described in this issue: https://github.com/libretro/RetroArch/issues/10363, the system tab icons shown in Ozone's sidebar (and to a lesser extent, the top left RetroArch icon) are very blurry at high scales and on large high resolution displays - for example:

This PR increases the resolution of the affected PNG images such that their visual appearance is consistent with the other menu icons (scaling has also been tweaked for greater uniformity):

Moreover, the system tab sidebar icons and main RetroArch icon are now generated via the export_ozone.sh script, so they can be updated easily in the future.

This PR closes https://github.com/libretro/RetroArch/issues/10363

[RobLoach]

Made an issue to double the size of XMB images a while ago too. On the Ozone icons it is very much noticeable considering their size. Thanks for addressing this.... May want to extend it to the other menu drivers if others notice similar issues.

[inactive123]

Yeah it would be a good idea if we could give XMB a serious look too.

[jdgleaver]

@RobLoach Doubling the size of XMB's icons doesn't seem like a good idea to me... It would increase loading times (textures get loaded all the time, on every context reset) and quadruple the memory usage. This is probably not an issue on most desktop systems, but on weaker platforms it's a pretty harsh burden to impose - especially when the vast majority of users run at 1080p (or lower)

I think it's also worth noting that the icons in the images you posted look worse than they should due to the transparent pixel colour issue we recently fixed. With the current PNG images, you get results like this:

...which look pretty good to me :)

If we were going to go with supersized assets, I think they'd have to be optional (i.e. selectable via a menu toggle).

[baxysquare]

As an experiment, I created 512x512 PNG files for Automatic and Systematic. Both sets have been run through Image Optim.

• At 256, the Systematic folder weighs in at 20.5 MB, while the 512 set is 43.2 MB.

• For Automatic, it's 8.7 MB at 256 and 16.7 MB at 512.

  I've wondered for a while if would be prudent to render icons at 16, 32, 48, 64, 128, 256, 512, & 1024 squared and then set the UI automatically switch based on resolution and/or user preference, similar to how it works in Linux, Mac and Windows. But I'm not sure how difficult that would be to implement in XMB, Ozone, etc.

[im4potato]

@jdgleaver Thank you for taking care of this! I've been looking at other areas of Ozone since I submitted the first issue and I've found a few other assets that could use a higher resolution image. I highlighted in red where the issues are. The selection rectangle around the currently selected item is blurry, and there is a very thin vertical grey line that seems to only appear on the left side of it. You can also see that the checkmark icon on the right is blurry as well. Here you can see that the information pop-up is also blurry. I don't know how it works internally, but I checked XMB and it does not have the same problem.

I can create a new issue for this if you would like.

[jdgleaver]

@baxysquare

I've wondered for a while if would be prudent to render icons at 16, 32, 48, 64, 128, 256, 512, & 1024 squared and then set the UI automatically switch based on resolution and/or user preference

This is a great idea in principle, but while it would be fairly trivial to add the icon resolution option to the various menus, there are some serious issues to work out:

• RetroArch is already very disrespectful of the user's storage, in that it requires the user to download and install a whole bunch of assets they will never use - i.e. a user will typically select one menu driver and one theme, and all those other assets are a waste of space. This doesn't matter so much on the desktop (where it's easy to manage files), but on platforms like Android everything gets dumped to an inaccessible system partition - so you're stuck with whatever the installer provides. The fact that a 512x512 Systematic theme is 43.2 MB is quite alarming! If we had sizes up to 1024x1024 for all themes, that would expand the assets bundle by hundreds of megabytes. It's unreasonable to force that on users.

• Expanding the assets bundle like this would also greatly increase the load on the buildbot - and that bandwidth costs money!

• Another storage issue: some filesystems exhibit reduced performance as the number of stored files increases. RetroArch is already pretty unfriendly in this regard - combine the assets, shaders, overlays, cheat files, etc., and that's a huge number of tiny files. Having full icon sets in 8 different resolutions will only make this worse...

• For large textures (1024x1024, or even 512x512) that are kept in GPU RAM all the time, it's pretty rough to use raw PNG files. We should really use a compressed-in-memory format like DXT for that kind of thing...

So this is quite a problem to deal with! If we were going to do something like this, then we'd need to implement a whole new way of packing the asset images. A naive approach might be to bundle each icon set as a zip archive (to reduce the number of tiny files, and hopefully save overall storage space) and implement a way for RetroArch to 'mount' these and read the contents directly (in the same way that LOVE2D can mount archives read only) - and then you'd also switch from PNG to DXT as the resolution passes a certain threshold (and that would require adding DXT support to RetroArch as well....). Given that the highest resolution icons will be huge whatever you do, there would also need to be some selective download options - i.e. ship the installer just with the base set (maybe 16, 32, 48, 64, 128, 256) and add the hi-def ones as separate entries in the content downloader.

That's a lot to think about...

[jdgleaver]

@im-4-potato Thanks for highlighting these issues!

The selection rectangle around the currently selected item is blurry, Here you can see that the information pop-up is also blurry.

Ah, these are tricky ones... They require an update both to the affected asset files and the code, so it's quite hard to synchronise this - i.e. if a user updates one and not the other (happens all the time...), then it will look broken. It needs some thought...

(BTW - the information pop-up is also blurry in XMB! It's just that the different colour scheme makes it harder to see)

Please by all means do open a separate issue for this - it helps us to keep track of things :)

and there is a very thin vertical grey line that seems to only appear on the left side of it.

That darker part to the left of the selection cursor is actually an intentional drop shadow effect. That was an aesthetic decision by the guy who made Ozone, so I don't want to meddle with that...

You can also see that the checkmark icon on the right is blurry as well.

Oh yes, that does look pretty bad! Certainly I can fix this.

Annoyingly, there's no source SVG for that image - so I'll have to make one. I'll get around to this soon :)

[im4potato]

@jdgleaver

BTW - the information pop-up is also blurry in XMB! It's just that the different colour scheme makes it harder to see

Maybe our scaling settings are different, mine is currently set at 1.25x and XMB looks good on my end.

Annoyingly, there's no source SVG for that image - so I'll have to make one.

Maybe I can save you a little bit of trouble, I just made one myself, although I don't know if it conforms to whatever icon standard RetroArch uses.

checkmark.zip

I apologize for being so nitpicky, I'd like to get more involved in this project but I'm not sure how helpful I'm being. Thanks again, I'll open another issue when I wake up.

[jdgleaver]

Hey, thanks for that!

I tweaked it a little, and did this: #355

It's odd that you're seeing this difference between Ozone's and XMB's message boxes - I get quite a different result. Let me investigate...

I apologize for being so nitpicky, I'd like to get more involved in this project but I'm not sure how helpful I'm being.

Never apologise for pointing out issues! If we don't know something's wrong, we can never fix it :)

Any input is helpful!

[jdgleaver]

Ah, okay - the scaling of those message boxes depends on several factors, due to the way that kind of texture is drawn... and in fact, there's actually a bug in XMB that causes it to look like that (the corner size value is wrong - but since it produces something agreeable 'by accident', I'll leave it alone for now...)

The only fix is to increase the resolution of the source image. We'll have to think about that.

[baxysquare]

@jdgleaver As someone who uses Lakka & RetroArch from desktop, TV and mobile devices, I appreciate the issues of resources and bandwidth since so many platforms are supported. I've worried for a while that this repository was getting bloated, which is why I originally moved my SVG and other source files to their own GitHub project.

Believe it or not, this is part of the reason for my call for unified themes & repository cleanup on #341. I think it would be cool to see the repository pared down to SVG source files and have the PNGs created as part of the build process for each platform. Perhaps that would cause more problems that it would solve, but it would trim the fat on the entire repository.

Another possibility would be for a specific platform to pick the pre-built PNGs from that are best for that platform, rather than picking up the entire repository. If it's low-end or mobile, perhaps it picks up 64 or 128 pixel icons. But if it's meant for a high-end it would pull 512 or even 1024. While it may mean the repository was bigger overall, perhaps it could make the final builds smaller.

[jdgleaver]

@baxysquare Yes, these are great suggestions. If we could just store SVG files in the assets repository (along with build scripts), that would be ideal - and it would serve as a clean starting point for any fancy packing approaches we might want to look at in the future.

This unification is probably quite a bit of work, though - XMB is very well provisioned, but Ozone uses a hodgepodge of stuff, and Material UI does it's own thing altogether. I can most likely source SVGs for all of Material UI's icons (they're mostly standard Android images, but with different colours and a few extras that I made), but this will take a bit of time and my TODO list is full already :)

Maybe Material UI can be left as-is for now, but then I'm not sure of the best way to handle Ozone - I know that the Switch guys have strong opinions about the overall look of Ozone, and would probably object to allowing random icon themes. So that would require some discussion...

And then there's the issue of building the icons - if the buildbot has to convert the SVGs for each build, that will take ages (the build process is already rather slow)...

In the shorter term, your idea of prebuilding PNGs of all sizes and just copying the required directory during the build process sounds good - i.e. it's probably not too much work, and should reduce buildbot bandwidth/storage requirements (it doesn't matter if it increases the assets repo size, since that's github's problem, not ours!). The one issue here would be deciding which build gets what - e.g. Android might be considered low end, but then what about users with a Shield hooked up to a 50 inch TV?

Or maybe something like this could work: the build process makes a best guess, but the online updater assets entry becomes a submenu with a list of available asset sizes (which then overwrite whatever is currently installed). So if a desktop user running at 720p doesn't want the default 512x512 icons, they can select 128x128 from the updater and automatically reclaim storage space + performance. And a high end Android user can grab 1024x1024 assets if they want to :)

[baxysquare]

@jdgleaver So what do you think about working toward the short-term goal using a brand new directory at the root of the repository? The other option would be to use the well-provisioned xmb directory as a foundation and then rename it once it was properly restructured. Here's what I'd propose:

/uni/ /uni/icons/ /uni/icons/themename/ /uni/icons/themename/svg/ /uni/icons/themename/png/ /uni/icons/themename/png/128/ /uni/icons/themename/png/256/ /uni/icons/themename/png/512/ /uni/icons/themename/png/1024/ /uni/fonts/ /uni/scripts/ /uni/backgrounds/ /uni/sounds/

This would reduce the concept of a theme to an icon set, moving the fonts and backgrounds to their own dedicated directories.

As for deciding which build gets what, I think that what you propose is reasonable. The best guess would likely work best for console and handheld builds. But the desktop and mobile builds may need some online updater provisioning to supplement.

[jdgleaver]

@baxysquare Yes, I like your proposal - and certainly this can go in a new root directory for now, to keep everything clean until we make the switch over. There are a couple of things I'm not sure about, though:

• For XMB at least, fonts are selected on a per-theme basis. So should that be /uni/fonts/themename?

• I still don't know how to best handle the unshared parts of the various menu drivers. Ozone has a number of icons that simply aren't relevant for XMB - is the idea still to include these in each themename directory? And Material UI has no shared icons with anything. I guess my point is that we can probably cobble together a shared theme format for XMB and Ozone (if someone is willing to make theme-specific variants of the custom Ozone icons), but Material UI is quite different, so I don't think it can be handled in the same way (the design intent is to only use Google-provided Material UI icons anyway). And then there are the menu widget images... Do we still keep all this stuff in separate directories for now? (Just with resolution-specific subdirectories?)

Also, I think it would be nice to have resolutions down to 64x64 (and even 32x32) for the handheld platforms.

As a side note, I have a backlog of around a month's worth of RetroArch work to do, so I can't contribute much to this at present - but after that, I'd be happy to work on any frontend code required to tie this all together.

[baxysquare]

@jdgleaver In terms of fonts, I can think of a few ways this could be handled, but there'd be some recoding involved.

1. At /uni/icons/themename/ there could be a specification file that would dictate the font, backgrounds and sounds. This could be like a linux .theme file, a windows .ini or an XML file and could contain common preferences as well as ones specific to each UI or even specific to each build if needed. Obviously I'm not a programmer so I'd default to whoever is handling that in terms of the how it's implemented.
2. Remove the default options from the theme files. Set a single default font and background for the XMB and let the user select their font, background and sounds from /Settings/User Interface/Appearance. Technically speaking, the end user can already override a theme's defaults anyway. This would just be "taking the next step" in that direction.

As for the unshared parts, I'd recommend we prepend a standard name for UI specific icons such as xmb -, ozone - and material -. For years I've wanted to do something similar to help distinguish between icons for the cores/systems and the base-level UI icons. As it stands, the best way to distinguish is that cores/systems have capitals in their names, while the base-level UI are all lower case. I think now is a good time to evolve.

In terms of implementation, I'm happy to rearrange my source repository in preparation. I'm also happy to get the uni directory structure in place and submit a PR so you have the infrastructure you need to start coding on the frontend. That way, we can have the assets structure ready and you can move forward whenever you're ready.

[jdgleaver]

@baxysquare:

In terms of fonts, I can think of a few ways this could be handled, but there'd be some recoding involved...

I do like your idea of using a theme file - that seems like a very sensible way to reference each type of asset, while keeping the asset files themselves well organised. For simplicity, we'd probably want to start out using the standard retroarch .cfg format (just key/value). We'd probably also start by setting this up for XMB (since that has the most rounded theme implementation at present), and extend it to Ozone etc. once the basics are fleshed out.

So for XMB, the theme file would point to an icon directory name, a font file, a sound directory and a background file - that would be no trouble to parse. (And then we just have some internal logic to select the correct 'resolution' subdirectory)

As for the unshared parts, I'd recommend we prepend a standard name for UI specific icons such as xmb -, ozone - and material -. For years I've wanted to do something similar to help distinguish between icons for the cores/systems and the base-level UI icons. As it stands, the best way to distinguish is that cores/systems have capitals in their names, while the base-level UI are all lower case. I think now is a good time to evolve.

Absolutely! That just seems like basic common sense :)

Not sure why your original issue didn't gain any traction - I can't see any reason not to do this...

In terms of implementation, I'm happy to rearrange my source repository in preparation. I'm also happy to get the uni directory structure in place and submit a PR so you have the infrastructure you need to start coding on the frontend.

I think it's probably best to focus on arranging your repo first - we do have to be somewhat careful about updating retroarch-assets too soon, since the packaging scripts are a bit ad-hoc, and we'd end up bundling the new uni directory in places where we don't yet want it...

If you get your local structure set up in a way you're happy with, then that can be the model we use when working out how to update all the code + scripts.

On a side note: are you on the RetroArch Discord? Because these are big changes you have planned, and it might be useful to have a little group discussion as these things move forward.

[baxysquare]

@jdgleaver

Sounds like we have a plan to move forward then. From here on, I'm going to put updates to this issue on #341. I have a PR I'm currently working on that attempts to bring Monochrome, Retroactive and Neoactive up to parity with Automatic and Systematic. Once that's done, I'll start the restructuring on my repo.

As for Discord, normally I can't participate because it's blocked by my employer. That said, I'll see what I can do to stop by and discuss.