This adds PR 10890's new setting to the Android GUI. I'm curious to see
if any Android users might get a performance improvement from it.
Due to how our settings work on Android, I haven't implemented disabling
the checkbox when the graphics backend doesn't support both GS and VS
for point/line expansion, but I don't think that's critical to have.
This is the first step of getting rid of the controller indirection
on Android. (Needing a way for touch controls to provide input
to the emulator core is the reason why the controller indirection
exists to begin with as far as I understand it.)
Compared to the previous solution of using big `synchronized` blocks,
this makes GameFileCacheManager's executor thread release and re-lock
the lock when possible, giving the GUI thread a chance to do a
(comparatively) quick getOrAdd call if it needs to.
This reverts commit fb265b610d.
The optimization in that commit is safe when the executor thread is
writing and the GUI thread is reading, but I had failed to take into
account that it's unsafe when the GUI thread is writing and the executor
thread is reading. (The native UpdateAdditionalMetadata function loops
through m_cached_files, which is unsafe if another thread is adding
elements to m_cached_files simultaneously.)
Losing out on this optimization isn't too bad, because
719930bb39 makes it very unlikely that
both threads will want the lock at the same time.
Because of the previous commit, this is needed to stop DolphinQt from
forgetting that the user pressed ignore whenever any part of the config
is changed.
This commit also changes the behavior a bit on DolphinQt: "Ignore for
this session" now applies to the current emulation session instead of
the current Dolphin launch. This matches how it already worked on
Android, and is in my opinion better because it means the user won't
lose out on important panic alerts in a game becase they played another
game first that had repeated panic alerts that they wanted to ignore.
For Android, this commit isn't necessary, but it makes the code cleaner.
If GameFile.getCustomCoverPath returns a mangled URI, we need to
unmangle it before passing it to Picasso, since Picasso has no
concept of Dolphin's mangled URIs.
In the past, directory initialization could fail for two reasons:
The user was rejecting the storage permission, or external storage
wasn't mounted. With the introduction of scoped storage, the first of
these two couldn't happen anymore; if the user rejects the storage
permission, we just use the app-specific directory instead of the
dolphin-emu directory.
By making it so Dolphin force quits if external storage isn't mounted,
we can get rid of our code for handling retrying directory initialization
after it fails. I think this slight hit to UX is worth it considering
that basically nobody has an Android device with detachable primary
external storage anymore. And the UX hit is very small; the user just has
to manually open the app again after remounting external storage. The
toast about external storage not being mounted will still be displayed.
The recent merge of the splash screen PR may have made it so that the
code for handling directory initialization failing doesn't work anymore.
To be completely honest, I'm not sure how to even test this in 2022.
JosJuice