(XMB) Increase the size of the icons

[RobLoach]

When on a high resolution HighDPI, the assets look very pixelated. Coming from: https://github.com/libretro/retroarch-assets/issues/187#issuecomment-348344515

Would be good to do two things:

1. Scale all built assets 2x up
2. Scale them down appropriately in the application

Then when on a high resolution, it wouldn't look pixelated.

[baxysquare]

My understanding is the XMB UI already takes the 256x256 PNG and scales them down to the size you see on screen. That's why it's so important for icon elements to snap to the 64x64 grid. When design elements do not line up with the grid, they tend to render oddly because of the downscaling effect.

In an ideal world, all the icons would render from SVG as discussed clear back on #8, but that's not really possible. At 1080p, 256x256 still seems like the sweet spot for downsampling, just like @Kivutar has it. Even at UHD/4K, we barely reach the point where a 256 icon would appear at full resolution as you can see illustrated below. The two big boxes are 256 while the rest are 128.

[baxysquare]

@Kivutar I'd really love to get your thoughts on this one. Do you think we're ready to move to a higher DPI?

[RobLoach]

Made this PR https://github.com/libretro/retroarch-assets/pull/197 to enable this easily. Here's a comparision on 2560x1440.....

256x256

512x512

When switching back and forth in the tabs, you can see the 512 is much sharper.

[alfrix]

you can see it sharper because you haven't used the same windowed resolution. to that isn't really an improvement in sharpness as much as the shadow getting bigger making the battery and clock icons look bad as @baxysquare said, the only reason ye would need 512px assets is to target 4130p, then the shadow should be fixed.

[RobLoach]

you can see it sharper because you haven't used the same windowed resolution.

You're right. Removed those ones. Thanks! Overall, I do see that having the larger images makes it sharper. Might just be me though.

[baxysquare]

Honestly, I'm good with whatever. If the team wants to move to 512, for me should be as simple as running an ImageMagick Mogrify command with a different percentage. I'm not sure if that's the case for other themes.

[RobLoach]

should be as simple as running an ImageMagick Mogrify command

Updating convert.sh over at https://github.com/libretro/retroarch-assets/pull/197 will do it. Does it for all the themes.

[baxysquare]

What if the SVGs are not included in the set? Mine are hosted as a separate project, primarily because my main source files are Illustrator PDF. The SVGs have been batch converted via Inkscape. Do you want me to add the SVGs back into my themes?

[RobLoach]

Ah, good point. We'll have to do those manually. Having the source SVGs don't hurt anything. They don't get installed when installing retroarch-assets. Completely up to you.

[baxysquare]

Hmm. Let me think on it. I've been running mogrify -density 288 -resize 25% -format png *.pdf to generate my PNGs for the repository direct from my PDFs, but if convert.sh is already doing it for all the themes, then perhaps I'll load the SVG files back in the mix. I'd be curious as to which one produces the better end result.

[RobLoach]

Convert uses inkscape, we could likely switch it to mogrify. Looks like a good solution. Unsure how they differ.

[baxysquare]

So I've been thinking a lot about how ICO, ICNS and even Linux based PNG icons require an output of icons at 16, 32, 48, 64, 128, 256, 512, & 1024 squared. Would the XMB benefit from having a complete set of icons and the XMB could choose what's best somehow?

As for using ImageMagick mogrify, I've had really good luck with PDF to PNG, but it stinks for PDF to SVG, so I currently use an Inkscape script from @alfrix for that. I'm guessing it would work great for SVG to PNG as well but I've never tried.

[baxysquare]

I've added the SVG files for Automatic and Systematic back into src/xmb so they can be part of the conversion process, and I will do the same for Retroactive and Neoactive in an upcoming PR. I'm not sure if that helps with this issue, but I figured it couldn't hurt.

[kivutar]

I think it's OK to go with 512x512

[alfrix]

i still think this is wasteful, and will make thing worse for 4k (3840)

the top asset is a chequerboard 512x512, and the one below (with the pointer) is 256

at 4k, notice that 256x256 is the only one that is not completely grey (1:1) (preferably use a viewer that is not affected by dpi at 100%, otherwise you'll see a moire pattern)

the fact that you are testing at 1440p causes this is because is downscaling at a non integer multiple. here is a 1:1 crop of your two images top is 256 bottom 512, it's a bit sharper, but with other issues on top, i wouldn't call it better

you can test it if you want: chequerboard 256 chequerboard 512

[baxysquare]

Where are we at on this issue? A while ago, @kivutar mentioned that moving to 512 would be okay. With Ozone becoming the default, I'm not sure it's relevant in relation to the XMB improvements mentioned in the blog post, but now's as good a time as any to decide to move forward with 512, or perhaps close the issue and leave it as-is.

I'm happy to update the themes I maintain, but figure it would be wise for Monochrome to upgrade, then the other themes to follow suit.

[baxysquare]

I'm in favor of moving to 512 or even 1024 if that's what decided. With 4K becoming standard and 8K on the horizon, I don't think it would hurt to move beyond 256.

Technically speaking, couldn't all the themes with a full set of SVG source files be automatically converted via script during the build process? If so, perhaps this could be a part of unifying themes & cleanup of the repository? I'd love to see the XMB theme icons available in Ozone.

[baxysquare]

Where are we at on this issue? It's been three years since the last comments and I believe we're still using 256x256 as the default.