Increased "White Flash" in newest updates???
-
@herb_fargus Ok. Do let me know, as I'm struggling to exactly visualize what it is you're experiencing, and what it is you're trying to achieve, but I'm more than happy to try to help materialize it!
By the way, I just updated the PR. No significant changes if you're testing - just removed the options from the menu, and forced the SVGs to be re-used on the Pi, for better memory management. Multi-threaded image loading is still the default, as it currently is - even though one can explicitly disable it via the settings file, I assume.
-
@pjft you are working overtime this weekend! Are all these modifications to the PR part of the merged ES that the retropie experimental menus script builds from? Thanks for all of you hard work and time. I need to stop checking my phone....everyupdate I see makes me want to test is that much more. That being said, I am loving the updates!
-
@TMNTturtlguy I'm just watching a terrible football match on TV, so I'm keeping myself entertained with this.
They are in my merged build as well, correct. Hopefully they'll be added to the main ES soon. If you want to help that happen, test this build here:
https://github.com/pjft/EmulationStation/releases/download/0.9/emulationstation
Instructions:
1 - Download it and copy it to your Pi
2 - Run, via SSH,chmod +x emulationstationin the same folder.
3 - Run./emulationstationYou don't need to have it in the actual ES folder to run as a one off. If you want it to be your permanent ES, just copy it to
/opt/retropie/supplementary/emulationstation. But right now, anyone who's having white flashes and such, you'd do everyone a great service if you test this out so that it can be merged into the main ES after testing.Thanks.
Edit: sorry, I thought this was on the other thread. You can just install from my script, correct!
-
@pjft thanks for the info, you better believe I will test and report back! You might want to copy and paste your instructions over to the other thread as well so that they see this.
What match are you watching?
Edit: looks like you already posted there as well! Thanks and sorry, I should read all my updates first!
-
@TMNTturtlguy nothing to write home about, just an end of season match between the soccer club I support back at home and a lower-end of the league table team. :)
Worst thing is that we're losing, and nobody seems motivated to do more as regardless of the result the team's standing won't change anymore in this year's league.
Shrug. At least I'm doing something useful before calling it a day!
Have a great weekend.
-
@pjft let me known when you are online
-
@TMNTturtlguy Hi!
So that was an interesting find. It does perform well with the PNG overlay, the main reason being that ES does re-use the PNGs by default. Even though it takes up slightly more memory, unsure why, maybe there's something in the PNG vs SVG handling code that makes it slightly better! Good find.
Looking forward to seeing what comes out of it.
-
@pjft so more development on my end with interesting results. In an attempt to get rid of .svg and going back to my original intentions for the theme of not reusing the controllers from carbon, I implemented my newest update to the theme. I changed the .svg to a .png. The image is still system specific so it changes with the system on the game selection screen. What I found is that lower resolution .png do not mean better performance. I started by creating the image scaled with the 720 background. I then cropped to size which is something like 356x375. To test I just placed in the theme. Looked great. Loaded up 17 and decided best to make them 256p so that the would use less memory and be a standard aspect ratio. The image quality reduced and because the pi had to increase the size of the .png to fit the maxSize box, performance was greatly reduced. I then tried 128 and had similar results. I went back to the odd 356 size, and performance improved greatly.
Next interesting item. The 25kb .png at 356 performs worse than the .svg file did. All I all I think I still have an ok setup, but it ran better with the .svg.
Just thought I would share as reading through old posts the conventional wisdom was that .png files would use the same memory as the original file size regardless of the scale in the theme, it appears to me after a few hours of trial and error that ES struggles with .png if it tries to increase its size.
-
@TMNTturtlguy Thanks.
Don't spend a lot more time on this - your previous theme was good.
I might have good news in the coming days.
Really good news.
-
@pjft Thanks on both accounts! My new updates are pretty cool, and the user can decide how the theme looks, you can revert to .svg controller or use with the new .png by simply changing a line in the Theme.xml from True to False!
-
@pjft you are truely a wizard :-)
-
Ok.
Should be good now - both on my repository, as well as in the other link.
Please test, go have fun all the way with ES running Slide animation without black or white flashes (99.9% guaranteed) - oh, and no more ALSA underruns as well, which also affected this.
I'll update the other thread.
-
@pjft just updated! i have to leave for a work meeting the rest of my day/night. I ran through it for 2 minutes and I must say, i cannot find a flaw yet! No flashing, no white boxes, super fast slide, VRAM 100 with 17 systems. Exit rom, no issues, no flash!
Will play more later to test the limits but i think this might be it! Amazing work. Thank you so much.
-
Works like a prince here. This is a first rate effort and it is much appreciated. The carousel's top speed is obviously a bit slower, but it gives it a surprisingly durable feeling somehow. I'm reading here that this was to allow addition time for texture buffering. It's all very impressive and has been most interesting to watch unfold.
-
@mediamogul Thanks for the kind words, and thanks you and @TMNTturtlguy for testing.
I did make the carousel top speed slightly slower, you are correct. If it's too noticeable, I'm happy to either add it as an option, or revert it. The reason is that, with the previous top speed, it would eventually show white flashes as it couldn't keep up with the required texture loading at that speed.
For simple calculations, what that speed meant was that every 150ms it would move to another system - so, in effect, it was trying to load (in theory) between 6 and 7 systems per second. For each system, we effectively load their logo and background, and buffer the neighbor logos and backgrounds, so we were loading in the best case scenario 6-7 systems * logo * background = 12-14 images per second, assuming it would re-use the neighbor ones in memory and not have to recycle them in memory. If a system has more than one image (i.e. background and overlay), you can effectively double that.
There's a significant throughput demand in those cases, either from SD card to memory to GPU, or just between memory and GPU, so slowing it down to 200ms makes it cycle (in theory) through 5 systems per second.
I thought it'd be a reasonable compromise, from testing, whereby you still get reasonably fast scrolling, but no longer experience a lot of blank textures from loading (unless the system does slow down for some reason, or maybe your textures take up more memory, or are not as compressed in the SD card).
The buffering helped mitigate some of this - so, if you cycle by 5 systems per second, it makes sense to try to pre-load/buffer the next 4-5 you're expected to load, just in case. And slowing it down to 5 systems per second helped keep this manageable within the memory constraints. They work hand in hand, complementing each other, rather than having been done in order for the other to work. Just to understand, previously we were caching only 1-2 extra systems forward and back at all times, but loading 6-7 per second meant that you couldn't keep up easily. When you were requesting the 3rd system to load, it wouldn't yet have fully loaded, and it would start loading as you were moving to the 4th - it was a losing proposition at all times.
Truth be told, for the masochist in me, I could try to get it to pre-buffer 7 and see if I can revert the speed back to where it was. Just out of curiosity.
Thanks for keeping up with this, all of you.
-
@pjft riding in the car to my meeting, thanks for the great explanation and detail on what you did. I actually found the slower cycling in slide a positive. It still moves much faster than anyone needs anyways. The whole feel of the movement and how clean each system logo and background loaded was so nice it just felt right! That being said, I need to spend more time with it, but I think the slower speed is very nice and would not recommend making an option or spending to much time on it. Just my opinion.
-
@TMNTturtlguy thanks. Yeah, I don't like to add options for the sake of adding them, there's an art in picking the right defaults.
That being said, fixing this did in effect bring a slower "fastest" scrolling that nobody had asked for, so even though it's a compromise, I can certainly see it as being a bargain that some didn't even ask for in the first place, and as much as I can rationalize that for myself, it's not something I ultimately like to pursue without validation.
I've also been on the receiving end of "minor UI changes" in apps that I use, that most people perhaps thought weren't relevant but ultimately affected me or my user experience negatively, so I'm open to feedback on that If people do complain. :)
-
I agree. The speed isn't a big deal. I have 41 entries altogether on the carousel and I'm still able to get from one end to another in a reasonable time. I certainly wouldn't complain about more speed either if it's something you end up experimenting with, but what you have done already is remarkable.
-
@mediamogul 41 systems! That is amazing, do you have video/meta data for all of that?
Staying on topic, well stated.
-
do you have video/meta data for all of that?
I have metadata and basic images for at least 90 percent of the games. Whatever can't be caught by Selph's scraper or the one built into ES, I don't stress over.
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.