Solution for " White Screen of Death "

Rookervik

Welp, I've suggested everything I can think of. I've made 3 or 4 themes and if you keep the assets small in size then you don't run into memory issues. You say your assets are small, so I can't really figure out what the problem is. Sorry. :(

KillerQ

@Rookervik

Even though this white screen of death has been addressed on the official emulationststion website, has anyone come up with a fix? I am on testing some theories this weekend.

herb_fargus

@KillerQ unless these theories include recoding the source code of emulationstation, all attempts will just be a band-aid that will barely address the symptoms rather than a cure. I know @fieldofcows had talked about some stuff he was working on with SQLite and the metadata and I'm sure he's been working on the wsod as well, but it's a pretty massive change

Rookervik

Where's this "Zoid Theme" hiding? I need to look at it.

Rookervik

@KillerQ And as Herb mentioned, there is no cure for the Raspberry Pi version of ES. There simply isn't enough RAM to use themes with large graphical assets.

EmulationStation renders the ENTIRE THEME onto a massive canvas. The viewing area is then slid around viewing this canvas. Changing systems, moving back to the system select. It's because of this massive canvas with all of the art pasted that the Raspberry Pi runs out of Video RAM. Desktop PCs tend to have gigabytes of RAM available for graphics. Not the Pi. So while the Pi can handle a couple systems with 1080p art... when you start adding more and more systems... the ES canvas gets gigantic and the pi just flat can't load all that art and keep it in RAM. There is no cure or fix for it. Just a reduction in the size of assets. That's all you can do because of how ES displays themes.

mediamogul

@Rookervik

You mentioned above that Carbon can load 60 systems before reaching the WSOD issue. Are there any factors that would compound the problem and lower that number, such as the addition of video previews or even an excess of scraped cover art?

Rookervik

@mediamogul Video Previews and Image Previews are loaded as-needed. Once you change your game selection, the old image is unloaded and the new image is loaded. You shouldn't ever run into WSOD just from previews. Previews are not part of the big canvas. They're overlays.

I tried to use this as a tricky way of having infinite wallpapers, but alas, the image previews load over the top of EVERYTHING else on the screen except the Logo graphic.

mediamogul

@Rookervik said in Solution for " White Screen of Death ":

I tried to use this as a tricky way of having infinite wallpapers, but alas, the image previews load over the top of EVERYTHING else

Clever thought though.

mattrixk

@Rookervik said in Solution for " White Screen of Death ":

I tried to use this as a tricky way of having infinite wallpapers, but alas, the image previews load over the top of EVERYTHING else on the screen except the Logo graphic.

And with that one sentence, you just dashed my idea of using UXS to create full-screen scraped images with a large fan-art background. Darn. Good thing I hadn't made it too far into it. Oh well, I can still make the theme, it just won't have the fan-art background.

I have a related question for you Rook. You said above that a 10x10 image uses as much VRAM as a 16x16 image, so you may as well use a 16x16. The new theme I'm making uses a custom UXS MIX profile to combine box-art, screenshot and game logo into one image, instead of just a single scraped image. At the moment that combined image is 440x440. Would it make any difference to the resources used if I just made it 512x512 instead? That way the image would be a bit crisper when it scales up.

Rookervik

@mattrixk That should be 100% correct. Everything should unfold into powers of 2 in Video RAM.

mattrixk

@Rookervik okay good to know. Cheers. (I'm still sad about not being able to use fan-art though)

fieldofcows

I haven't looked at the wsod problem in any detail yet but I can think of two options to address this from the top of my head:

With the changes I'm making to the metadata I should be able to make ES contain only a single 'game list view' and dynamically change it when the selection changes meaning you would not have the giant canvas anymore. This needs further investigation to see how difficult it will be. I can imagine that keeping the context of each 'system' will be an issue
Implement some sort of texture manager that manages the texture memory based on what is currently on display. The manager will keep track of where the texture is used on the canvas and if it is not currently on display then it is a candidate for being purged if texture memory is low. It can then be dynamically reloaded when needed again.

I haven't yet run into the wsod problem myself. If I had then I surely would have had a closer look. Is there a simple way to reproduce this without having to configure a large system? Is there a config someone could easily share without breaking forum rules? (i.e. no ROMS)

fieldofcows

@mattrixk said in Solution for " White Screen of Death ":

(I'm still sad about not being able to use fan-art though)

What do you need for this to work?

mattrixk

@fieldofcows said in Solution for " White Screen of Death ":

What do you need for this to work?

I don't know how much work it would be (and I've mentioned it on another thread), but I'd love it if we could have the option to add multiple images to a ROM.

On vanilla ES, there is only one Image field in the metadata (<image name="md_image">), but in your Video Preview mod, there is also <image name="md_marquee">, so I'm curious how hard it would be for you to add more Image fields to the metadata.

I suppose the easiest would be just having a second Image field (called <image name="md_image_2"> or something), which I could use for fan-art, but to be honest, I think it would be fantastic to have a separate Image field for each Image:

Fan-art
Box-art
Screenshot
Game Logo
Marquee

That way a themer could have a lot more display options. There may be others, but I think they are the main ones. Maybe even an "md_image_misc" just for use with random images someone might want to put in there.

While I'm on the subject, would it possible to change the z-index of all the metadata fields? At the moment, I think "md_image" sits on top of everything else, no matter where the code for it sits in the XML file. It would be great if we could set the hierarchy of all the metadata fields so we could put anything in front of anything else.

EDIT: an idea for sparking the WSOD:

You can take empty .TXT files and name them game.zip and put one in each system folder. The systems accept take zip files will read these as games and show that system on the System view (you obviously won't be able to scrape or play them, but you won't need to).

Then change to the Simple theme (or another theme with 1080p background images). If you don't have enough systems, go through them one at a time and change game.zip to game.[whatever extension that system accepts] until you have enough to cause the WSOD.

(I haven't tested this, but it should work)

KillerQ

@Rookervik said in Solution for " White Screen of Death ":

@mediamogul Video Previews and Image Previews are loaded as-needed. Once you change your game selection, the old image is unloaded and the new image is loaded. You shouldn't ever run into WSOD just from previews. Previews are not part of the big canvas. They're overlays.

I tried to use this as a tricky way of having infinite wallpapers, but alas, the image previews load over the top of EVERYTHING else on the screen except the Logo graphic.

Thanks for all the info. Reducing image sizes the simple theme allowed me to have 23 systems with no issues whatsoever - but it's still a bandaid.

You mentioned hat video clips are treated differently as they load when the system is selected - as opposed to being always on and loaded in the background similar to the background canvass.

What if you told each system selection screen to have a one second (to reduce waste) fullscreen 1080p video clip hat remains paused. This would serve the same purpose, but I wonder if it could be forced into the background?

Just thinking out loud.

Rookervik

@KillerQ It's a hack, but it sounds like it would work. But if you're going to tweak ES to load a video in the background, just tweak it to load an image in the background as soon as the screen has stabilized. Either way, it won't look pretty when you're changing systems. But after you get into the next system and the background loads it will be fine.

I, for one, don't really care to have a different wallpaper for each system. There are a lot of tricks you can do to make wallpapers different for each system that don't require big full-screen graphics. Tint the wallpaper, add small images to it, and so on. You just have to be a little creative.

If having a different wallpaper is that important, use Attract Mode. That already supports a different theme for every system. :D

KillerQ

Thanks for the quick reply. There MUST be some way to crack this problem. There ls always a way - lol.

I'm tempted to try split images or something else out of the box.

I'll report back.

I'm also gonna figure out how to have it load a background once the screen is stabilized for a particular system.

fieldofcows

Ok, I may have a simple-ish fix for this. I've just tried modifying the TextureResource component in EmulationStation to keep textures in conventional RAM instead of texture memory and only use texture memory when bound during rendering, freeing it once the render operation is complete.

On my Linux system this works perfectly and there is no noticable delay when rendering the images. I have yet to try this on the RPi to see if it works ok. I'll give it a go and report back.

Just as an illustration, I've logged the texture memory that would have been used with the current ES compared with the texture memory used in my modified ES for textures - note that this does not include textures used by fonts at the moment so doesn't give the total texture memory that is used.

Theme used: Nismo's excellent OldRoom 720p theme (maybe not the latest version)
Number of systems: 13
Texture memory used by TextureResource in current ES: 97Mb
Texture memory used by TextureResource in new ES: 3.5Mb

Fingers crossed this may be a solution for the WSOD problem :D

mattrixk

@fieldofcows said in Solution for " White Screen of Death ":

Texture memory used by TextureResource in current ES: 97Mb
Texture memory used by TextureResource in new ES: 3.5Mb

I don't know much about what you are doing, but that number difference is none-the-less very impressive.

fieldofcows

Well my change definitely seems to solve the problem but it still needs a little bit more work. Regenerating the texture on every render is a bit too much for the poor RPi to handle so it makes the rendering sluggish. It shouldn't be too hard to fix.

I tried 'zoid' and 'oldroom 1080p' themes with the maximum amount of systems. Without my changes both failed to render. With my changes they rendered fine, albeit slowly.