Solution for " White Screen of Death "
-
There's a minimum amount of VRAM required to display certain size wallpapers. If you have just 1, 1920x0180 wallpaper, you MUST have 256 meg RAM split. But that 256 RAM split will take you up to 10 or so wallpapers. The next jump is probably 512 split. Which should still be just fine with most of the emulators that the Pi can handle.
You can make sure your theme wallpapers are 720p and that will help you with the RAM issues. ES was not designed for the Pi, but it works.
The Carbon theme was designed for the Pi's limited video RAM just for the white screen problems. If you're going to make some custom themes, try thinking in 'parts' instead of 'wallpapers.' Several 512x512 images take less VRAM than a 1920x1080 wallpaper. Try to re-use elements so ES doesn't have to fill VRAM with a massive picture.
-
Thread moved - help questions should go to the help & support area.
-
@Rookervik said in Solution for " White Screen of Death ":
There's a minimum amount of VRAM required to display certain size wallpapers. If you have just 1, 1920x0180 wallpaper, you MUST have 256 meg RAM split. But that 256 RAM split will take you up to 10 or so wallpapers. The next jump is probably 512 split. Which should still be just fine with most of the emulators that the Pi can handle.
You can make sure your theme wallpapers are 720p and that will help you with the RAM issues. ES was not designed for the Pi, but it works.
The Carbon theme was designed for the Pi's limited video RAM just for the white screen problems. If you're going to make some custom themes, try thinking in 'parts' instead of 'wallpapers.' Several 512x512 images take less VRAM than a 1920x1080 wallpaper. Try to re-use elements so ES doesn't have to fill VRAM with a massive picture.
On the system select screen it is still carbon on the inside its custom. the pics are really really tiny because i made them previously on the simple theme and it uses the stretching. Most of the pics are around 10x10 pixels. They have different fonts in each console though. The fact that i can have eleven of them on 256 megs but cant have 14 of them on 384 makes no sense.
-
That is very strange. A 10x10 pixel image will take the VRAM of a 16x16 image. Everything unwraps to a power of 2. As long as these images are not SVGs. An SVG stretched to full screen takes a canvas to display, and that canvas takes the full VRAM of that area. So even if the SVG has a single line in it, and the file size is 0.5kb, it will take the same VRAM as a 1080p PNG uncompressed. Fonts shouldn't take too much RAM, and they are regular RAM. Try 512 RAM split. 384 hasn't ever made any difference for me before.
If you're still bothered by things, you can try zipping up the theme and sending it to me. I can look at it and figure out what you problem is.
-
@Rookervik said in Solution for " White Screen of Death ":
That is very strange. A 10x10 pixel image will take the VRAM of a 16x16 image. Everything unwraps to a power of 2. As long as these images are not SVGs. An SVG stretched to full screen takes a canvas to display, and that canvas takes the full VRAM of that area. So even if the SVG has a single line in it, and the file size is 0.5kb, it will take the same VRAM as a 1080p PNG uncompressed. Fonts shouldn't take too much RAM, and they are regular RAM. Try 512 RAM split. 384 hasn't ever made any difference for me before.
If you're still bothered by things, you can try zipping up the theme and sending it to me. I can look at it and figure out what you problem is.
So changing the
gpu_mem_1024=500
made absolutely no difference. Most of my themes have an 8x8 solid color block. Maybe 2 of them. If they need a stripe on the top it might have a 1x343 pic. A few of the ones i have working have a pic of woodgrain or metal for the top or bottom less than 350x350. None of the 3 / 4 themes i am trying to add use more than 2 8x8 pics. None of the ones i am trying to add have a pic bigger than 8x8.EDIT: is there a way to verify how much ram is being used for the gpu? I have a whole extensive overclocking list of stuff that i got from someone online for running n64 games and when i had it all set in the config.txt it made absolutely no improvements. And that had my cpu overclocked at 1450 and i saw no improvement. So im not sure if the themes my problem now or if overclocking and ram split is a problem. I have to have force_edid_audio for the sound to work on my tv but i wouldnt think that would affect this. It tells me it cant be overclocked in raspi-config on both 3.7 and 4.0 beta 2. I will start a new thread on the config.txt problems if that is my issue
-
So tell me, is this white screen a completely white screen, so you can't see anything, or is it a white theme with none of your theming elements? From what you're saying, you are actually using less assets than Carbon itself. Which can load 60 systems without RAM issues. Does your theme look like this when you load it? If so, the theme xml files have errors in them.
Also, keep in mind that the RAM splits should stay in powers of 2. Just like any images you use in the theme. 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096... Your 1x343 image uses the same RAM a 512x512 image would take, as does the 350x350 image. They all unfold to a power of 2 in VRAM.
-
@Rookervik said in Solution for " White Screen of Death ":
So tell me, is this white screen a completely white screen, so you can't see anything, or is it a white theme with none of your theming elements? From what you're saying, you are actually using less assets than Carbon itself. Which can load 60 systems without RAM issues. Does your theme look like this when you load it? If so, the theme xml files have errors in them.
Also, keep in mind that the RAM splits should stay in powers of 2. Just like any images you use in the theme. 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096... Your 1x343 image uses the same RAM a 512x512 image would take, as does the 350x350 image. They all unfold to a power of 2 in VRAM.
No my theme stuff is not blank. All the themes i have added and are trying to add all work. I just boot to a pure white screen when i have too many of them.
-
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. :(
-
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.
-
@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
-
Where's this "Zoid Theme" hiding? I need to look at it.
-
@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.
-
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?
-
@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.
-
@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.
-
@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.
-
@mattrixk That should be 100% correct. Everything should unfold into powers of 2 in Video RAM.
-
@Rookervik okay good to know. Cheers. (I'm still sad about not being able to use fan-art though)
-
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)
-
-
@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?
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.