Increased "White Flash" in newest updates???
-
@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.
-
@pjft @mediamogul inspired by, but not to one up @mediamogul I loaded up 40 systems with the comic book theme, and it ran like a dream! Now, that being said, 20 of the systems only had 7 games in them, but they were all loaded with video and images! Nice work @pjft truly amazing stuff that you accomplished this week.
-
@TMNTturtlguy I may have a small request for you on the side, not urgent and certainly not in any way important, but perhaps useful for 3-6-9 months down the line for ES. And likely none of these will result in anything.
I'll reach out at a later stage, either via here or via GitHub.
-
@pjft Sounds Great, just let me know!
-
@pjft I just had 62 systems running when final testing the theme - ran super smooth!
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.