Add lastgood configuration to Loadsettings for guisettings #6
Conversation
remove cflags that aren't safe
This is useful for packagers as they can override menu defaults in as.xml
rather than patching xbmc code.
Usage example:
<hidesettings>
<setting>lookandfeel.soundskin</setting>
<setting>videoplayer.rendermethod</setting>
</hidesettings>
place a guisettings.xml in system with any default values needed. These values will only be used when user's guisettings.xml is generated. This way, packager can set a default value (for ex, disable rss). Each profile will default to this setting, but user's changes will take precedence.
If we're using bypass mode for playback, we aren't rendering ourselves, so don't try to wait for render events.
(texture * color) costs us an extra operation on Mali when sent as varying. Instead, since textures use the same color for the entire render, send it as a uniform instead. This does not apply to fonts, since the font and its shadow are rendered together, and may not share a color (tested and looks bad). This increases fps anywhere heavy blending is done.
Mainly seen when we're fading in/out. Mali likes this ordering better for some reason, ops go from 3 to 2 (according to their profiler). Verified with PVR's compiler that there is no change, it's 2 there either way.
Gives a considerable speedup in scenes with many bordered images (like settings).
The only chipset I'm aware of that can do dxt on arm is Tegra, and that's not worth slowing everyone else down
With d-r on, speeds up video playback+gui nav very significantly. We still do the fake render, so the player still receives its render callbacks.
…s. pick one, please
If guisettings == OK, then make a copy to .lastgood If guisettings != OK, then rename to .bad and try to load .lastgood if guisettings != OK, and .lastgood not exist or bad then Reset.
|
nak on this, it would never be accepted upstream and it would be much, much better to figure out why guisettings.xml is getting corrupted. If guisettings.xml is getting broked, then lots of other things are also getting borked. |
|
The problem is, that without a modification like this its virtually impossible to figure out why guisettings.xml gets corrupted. Because xmbc's recovery from an error is destructive to the evidence you need to find the errors. By the time you have figured out that guisettings got screwed up on your next boot, its already been overwritten by xbmc. You have lost all evidence in the file structure to be able to determine if its a crosslinked file, an addon causing bad settings to be written into the files, etc. Error messages in the log tell you what line in the xml is screwed up but doesn't give you a list of every line that is screwed up. |
|
Hello everyone, any news on the guisettings.xml corruption bug? I am trying to figure out a workaround to backup the guisettings.xml every now and then and revert to it if it gets corrupted, but it's only a hack to the real issue :/ Thanks for the contributions to the project! |
|
it would be good to understand exactly the conditions under which guisettings.xml are getting corrupted. I never see this happen for me and I abuse my aml devices under testing pretty hard. |
If guisettings == OK, then make a copy to .lastgood
If guisettings != OK, then rename to .bad and try to load .lastgood
if guisettings != OK, and .lastgood not exist or bad then Reset.