Solution for " White Screen of Death "
-
@fieldofcows I was just about to post that link. You beat me to it!
-
I believe the build should work on the RPi2 as well if anyone wants to try it but doesn't have a RPi3 - although I cannot confirm this as I don't have a RPi2 myself.
-
@fieldofcows Initial reports: huge success! It fixed the dropped textures I was seeing, although there is that slight but noticeable hitch as I cycle through the carousel and force new textures to be loaded. The only bug I have found so far is that if you are pressing right or left while the load is happening, it reacts as though the input key is being held down. This only happened once, and I have not been able to replicate it yet. Edit: It looks like if you move in one direction (either left or right) until textures start to load, then start moving in the opposite direction, as soon as you hit the end of the cache, where new textures have to be loaded, the "onKeyRelease" event (or whatever it is in ES) doesn't register, causing the input to loop. This is easily fixed by the user by simply pressing and releasing that key.
I can also confirm that 120mb is the upper limit before textures start getting dropped (at least on my system).
Will investigate further and try various ROMs as well.
-
@fieldofcows I've tried a variety of ROMs, on a variety of systems (including PSX, N64, and Dreamcast), and have not noticed any performance change from the prior official RP build of ES. The closest I came to seeing any gameplay change was graphical glitches in one of the N64 ROMs I tried, but that emulator has always been glitchy for me, so it's very possible that nothing has changed in that regard.
Overall, I'm extremely happy with the change. The only thing I might suggest is that instead of a least-recently-used cache, to keep textures in the cache based on proximity to the currently selected system. In my case, I have 18 or so systems loaded, and the cache can only contain about 10 of the images (modified tronkyfran theme with 100mb VRAM limit). To go right one index is more likely than going left 11, so it might reduce the loading hiccup if the farthest systems are unloaded and the closest systems are kept in memory. Edit: even better would be to do this on a background thread if possible, which could prevent any noticeable hiccups as textures load and unload.
At this point, that's really a nitpicky request, though. You've just fixed one of the biggest (and longest-lasting?) bugs in ES, and I'm sure the community will be very happy about that!
-
@MWGemini Brilliant. Thanks for that. Yes, I'm already looking at prioritising the systems around the currently selected system - great minds think alike.
I have considered a background thread because this would completely cure the jerkiness at the expense of seeing images appear over time. I'll take a look but I'm not sure how easy it will be to make the texture code thread safe.
-
@fieldofcows said in Solution for " White Screen of Death ":
This cache is configurable in es_settings.cfg and via the UI in "Other Settings" -> "VRAM LIMIT". The default is 100Mb and I can push my RPi3 to about 120Mb before it starts dropping textures. Note that this limit does not include fonts which load on top of this limit.
i don't know if it's useful, but
sudo vcdbg relocgives you the free vram (in a bit of an unwieldy format)
sudo vcdbg reloc |grep "\[" | awk '{split($0,a," "); print a[12]}' | awk '{split($0,a,","); print a[1]}' | awk '{sum+=$1}END{print sum}'this gives it in bytes (stole this from somewhere.. not sure if it's properly working)
vcgencmd get_mem arm vcgencmd get_mem gpugets the memory split for system and gpu respectively.
obviously you need some sort of fallback for none-pi systems, but maybe this could be used to pick the cache? not sure.
-
@fieldofcows I looked through your last commit, and I've got an idea for prioritizing textures based on proximity to the current system, but it would involve a data structure change. I can't think of a way to do it with the current implementation (sorry!), but I also only looked through your changes, and have not dug through the rest of the code. That being said, feel free to ignore the rest of this post if it's completely stupid :). You know the system far better than I do.
If you've got an array (or ArrayList or equivalent), and each index represents a system (or a particular filter or view, from the metadata improvements I described), you can just start putting textures into your cache starting from the first index and moving outward in both directions one index at a time. When the cache is full, stop. Every time the user moves from one system to another, just unload the most distant system from the opposite direction and load the next closest (not yet loaded) system in the current direction. Edit: you'd only need to keep track of the current index (which I think you already have), and the left and right extents. The array could just be an array of bits, as well (loaded vs not loaded), to save on memory.
For example, if there are 20 systems and the user is at index 10 and the VRAM can hold 10 textures, the cache will hold items 5 through 14 (or 6 through 15, depending which direction you start with). Moving to the right would unload 5 and load 15, whereas moving to the left would unload 14 and load 4. Wraparound can be handled with modulus. With the metadata improvements and custom views/filters, that would just involve updating the array and the loaded textures each time a view is created or deleted. I also thought about using a modified red/black tree or something similar, but figured that the array would be the simplest to write and probably the fastest to execute.
I also tried to look through the code to see if I could spot where the "onKeyRelease" event is getting lost, but couldn't spot it from my relatively short read-through.
-
Guys if you need some "big" theme to test I can upload the uncompressed and unoptimized 1080p version of oldroom, it has very heavy images... XD
But it "only" has 21 systems right now.
Edit: Even with that amount of systems, and that heavy theme, I don't have white screen under windows OS, so maybe it's a Rpi only problem... btw I have 8gb ram.
-
@Nismo Sure, if you want to upload it, I will test it on my Pi. If you also have a compressed/optimized version, I can test that one too and compare the results.
-
@MWGemini ok, i'll upload in a minute.
-
@MWGemini Here you have all new oldroom 1.8 themes in one single zip file: http://www.mediafire.com/file/ph8g8jh7s2vfayi/oldroom_themes.zip
- Crude original not optimized version (22.8mb)
- 1080p version (13.9mb)
- 720p version (recommended) (9.31mb)
Enjoy.
-
@Nismo I tested all three variants. The first two could not fit in my 100mb cache, so there was the normal hiccup as systems loaded and unloaded. The third fits entirely in cache (58.45mb with my systems), so transitions are very smooth.
I probably don't have the images scraped in the way that your theme is expecting them, because all I see on the detailed view is an empty desk (no TV or anything), but in terms of the white screen, @fieldofcows appears to have it fixed.
One thing I did notice is that while switching from one theme to another, all systems were loaded with white backgrounds, and I had to drill in to the system and drill back out to start displaying the images and ribbon. In fact, it did appear to be a full WSOD- no ribbon or anything else displayed, only the debug data. Minor annoyance, but figured it was worth mentioning. When switching themes, the cache appears to be loaded (based on the RAM debug numbers), but the images don't appear at first. I also tried just switching themes and letting the Pi sit for several minutes to see if it was a latency or timing issue, but that did not appear to have any effect.
-
@MWGemini You don't see tv's because the video view is not loaded. That's because you doesn't have video tags in your gamelist.xml, you need almost one game with video tag in gamelist.xml and then the video view will be loaded for that system.
About the systems with white background it doesn't happen to anybody with the current version of ES, you are the first one that have that problem, maybe it's the new WSOD fix that have some strange behaviour.
Make sure the system exist inside the oldroom theme folder, only 21 systems supported right now.
-
@Nismo I would be fairly certain that it's just a bug in the WSOD fix and has nothing to do with your theme. I've tested a bunch of different themes now (both with and without video) and they all exhibit the same behavior.
-
-
@fieldofcows Working well, as far as I can tell. There is definitely a noticeable hiccup when scrolling through the system carousel, but considering that the alternative is a completely unusable system, I think it's a great improvement.
I also noticed that while installing new themes via the Retropie->Retropie Setup script that the setup program was slow to respond to inputs. I've never seen that before, but it might be completely unrelated.
-
I've been working hard on this over the last couple of days. I wasn't happy with the jerkiness that is introduced when the memory limit is reached, especially as we have some CPU cores sitting there idle.
After some experimentation, I determined it would be too hard to make the current TextureResource load in a background thread so I've done some fairly extensive surgery on this area to tidy the code up, provide a maximum VRAM limit as before but reload images from disk when needed in a separate worker thread, instead displaying a placeholder image whilst it's loading.
I've just got it to the stage where I can try it out on a RPi3 and I'm pleased to say it runs as smoothly as anything. I've still got some work to do (SVGs often render upside down, add some more thread safety and I would like to blend from the transition image to the loaded image rather than just 'jumping') but it's looking good.
-
@fieldofcows sounds great :)
-
@fieldofcows I second what @BuZz said- sounds great! Let me know when you have another version that you'd like me to test, or if you'd like some help on the dev side.
-
Thanks guys - I was very wary of submitting the previous fix. I can just imagine new users that have never seen a WSOD saying "I've added 20 systems and ES has gone slow and jerky". Hopefully the new fix will solve all that.
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.