ToDo: optimize menu creation

[clsid2]

Currently the player menu is being recreated each time something in it is changed. For example pressing pause means the first entry in the Play menu needs to be changed.

Investigate ways to optimize this and avoid unneccarry changes.

Maybe the recreation can even be delayed till the moment on which the menu is clicked on. When it needs updating, simply flag it as "outdated" with a boolean parameter. Then once the menu is accessed, then recreate it on demand.

Additionally, update only the parts that need changing.

[adipose]

https://github.com/clsid2/mpc-hc/pull/2603

Maybe the recreation can even be delayed till the moment on which the menu is clicked on. When it needs updating, simply flag it as "outdated" with a boolean parameter. Then once the menu is accessed, then recreate it on demand.

SetupRecentFilesSubMenu() actually is called in OnFilePostOpenmedia, but it is also called dynamically. I'm not sure what the point of doing it immediately is, but it would probably work to just comment out that first call.

[adipose]

OnUpdatePlayPauseStop is called regularly by MFC. This controls whether the menu elements are enabled or checked. It is important for menu items to be enabled even when the menu isn't opened, because the same IDs are used to control whether the action can be taken via shortcut.

OnUpdatePlayFramestep has the same pattern. If you allow ID_PLAY_FRAMESTEP to remain disabled until you open the menu, when you press CTRL+RIGHT, it will not trigger OnPlayFramestep. You can test this behavior by changing this code block:

Approximately every second the player is running, all of these Update routine are called to update the menu items. This is probably not a huge performance issue, but if so, we might want to cache the calculation rather than the enable/check setting. It probably doesn't cost much to update an item from checked to checked (no change), for example.

Candidates for rebuilding the menu include SetupShadersSubMenu. It is called dynamically, though, which means it's only being built when the user opens that menu. Subsequent opens of that menu are wasting effort. To optimize, we'd have to track whether the current preset has changed, or the list of presets.

I don't know whether rebuilding the menu is costly. Maybe just looping on the menu to verify it is identical to what you want is a generic solution.

[clsid2]

In case of for example OnUpdatePlayFramestep we could do the calculation just once, and reuse it for as long as file is loaded. Probably also for several other similar functions. Calculate the capabilities for menu purposes in OnFilePostOpenmedia. Clear them in CloseMedia.

Probably a whole lot of work to do and requires lots of testing. Might not be worth the performance gain. There is no actually problem we are trying to solve here. Better to move on to more important issues.