October17 refactor month, Game Screensaver and more

[Hex]

As we go on adding more and more Scteensaver types into a single class everything is becoming difficult to manage. I would like to dedicate the next month into refactoring the entire screensaver handling and make it modular and streamlined.

I would also like to ask the devs if you would be interested in using this month (October 2017) to refactor and simplify the code you are comfortable with. This would be helpful to reduce code complexity and increase further development. We can even use this time to squash bugs.

On the screensaver side, there was a request to make a screensaver that cycles through these steps; starts an emulator, runs it for a set time and closes the emulator. What do you think of this

[Hex]

@pjft @Zigurana @jdrassa @meleu @herb_fargus @TMNTturtlguy

[herb_fargus]

@hex said in October17 refactor month, Game Screensaver and more:

there was a request to make a screensaver that cycles through these steps; starts an emulator, runs it for a set time and closes the emulator. What do you think of this

I personally dislike this idea. How much feature creep are we going to add? what's the benefit to this? video game roulette?

I've always been of the opinion less is more, I prefer minimalist setups and and anything that makes ES more like hyperspin is a cancer imo.

I don't make the code decisions or do much code so I'm not going to pretend anything I say is definitive and I'm sure many others will probably have a different opinion.

[BuZz]

I don't think we need any more screensaver modes. I'm not against code cleanups in general so long as they don't introduce new bugs (so they must be well tested). Am more interested in bug fixes than new features in general - some of the new features such as the power saving modes (which I am not completely sold on, but accepted) introduced a fair few issues meaning I had to rollback the ES binaries etc (and still there are ongoing problems related to the power saving modes from my understanding)

[Zigurana]

@herb_fargus said in October17 refactor month, Game Screensaver and more:

How much feature creep are we going to add? what's the benefit to this?

The way I see it, there is always a tendency for new feartures to be added. At the start, this is harmless, and users will welcome the new functionality (mostly). After a while though, new features clutter up the user interface, and the overall experience is degraded.

Now, if I understand @Hex correctly, he wants to improve maintainability of the code by restructuring and cleaning up. If you ask me, this needs to be accompanied with a cleanup of the UI as well. Not only to streamline menus and functions, but also to make though decisions on which functions are worthwhile to keep in the first place.

These decisions should be well informed, maybe based on an extensive user-survey, so that developers know where to look for improvement areas.

So, tldr: After a season of strong growth we should consider pruning, if only to allow growth in the next season.

[Zigurana]

@hex
This is a splendid idea! Rather than working on your own code, though, I would suggest working on areas that you have not touched before. It is all too easy to slip into the same mistakes twice, simply missing the same logical inconsistencies as you did the first time around.
Another benefit is that you automatically get a well informed reviewer, at least for those features whose dev is still around 🤣.

[Zigurana]

@buzz said in October17 refactor month, Game Screensaver and more:

I'm not against code cleanups in general so long as they don't introduce new bugs (so they must be well tested).

That is by far the most critical part of this exercise: we need to get our code under test.

Building unit tests is no-ones idea of having a good time, but it is critical to quickly prove that intended changes do not affect the functionality.
So I think we need to decide on a framework (gtest?) and start the process of creating module-level tests, if only for the newer stuff we've added these last two years.

[Hex]

@buzz said in October17 refactor month, Game Screensaver and more:

new features such as the power saving modes (which I am not completely sold on, but accepted) introduced a fair few issues meaning I had to rollback the ES binaries etc (and still there are ongoing problems related to the power saving modes from my understanding)

Since Powersaver touched the core logic of processing, this was to be expected. I apologise for the rollbacks you had to do. Many of the bugs were edge cases that were not caught. Slowly and surely they will be. There is no precedent to reduce the frame rendering and hence no specific guidelines.

[Hex]

@zigurana said in October17 refactor month, Game Screensaver and more:

Rather than working on your own code, though, I would suggest working on areas that you have not touched before. It is all too easy to slip into the same mistakes twice, simply missing the same logical inconsistencies as you did the first time around.
Another benefit is that you automatically get a well informed reviewer, at least for those features whose dev is still around 🤣.

I agree on this. At the end of this we will have multiple devs having knowledge about how each aspect works. This will add more eyes to review the code.

[pjft]

I think this is a good idea, though not one to be taken lightly. Refactorings and cleanups are often double-edged swords, and while I am always supportive of investing time in such endeavors, I fear that we may introduce new bugs and/or remove code that was put there for a reason, even though it might not be at all apparent.

If the scope is more or less well defined upfront (i.e. if we determine that we will look into the screensaver code, or something more), I'm fine with that.

I'm not sure this needs to necessarily be a cross-coordinated effort, though - these efforts are always welcome as long as they're well tested, I believe.

There are a few things on my plate that I'd like to look into, ES-wise, that don't fall into the "new developments" area but rather in the "fixing/improvements" area, namely (in no particular order):

• Document OMX and collections features, namely Predictive Profile (High 4:4:4) not working [EASY-ISH]
• Address textures defaulting to white after returning from an emulator. [MEDIUM?]
• Improve texture cache to reduce texture pop-in. [MEDIUM?]
• Fix or mitigate VRAM handling, especially on out-of-memory scenarios. [MEDIUM?]
• Try to get rid of the two video player options, but rather have a default hardware accelerated player for the Pi that works as intended (i.e. respects the actual layers, rather than being a separate process). [HARD]

I honestly have no idea how to go about several of these, but I secretly hope that with a proper Windows and VS debugging environment I'd be able to make some progress here.

Thanks for starting this.