This reduces the build time for incremental builds from about
2 minutes to about 20 seconds. Most people never run the
unit tests on Android anyway (I'm not aware of anyone other
than me ever having done it).
Any local references get cleaned up when returning to the JVM,
but some of the functions in AndroidCommon return to C++ rather
than the JVM, and functions with loops risk running into the
limit of how many simultaneous local references are allowed.
I was going to rename this to getSysDirectory to make it clearer
what the returned path actually is, but it turns out we're not
actually using this for anything anymore.
The Java implementation of getting the list of post-processing
shaders only looked in the Sys folder and not the User folder.
This could be fixed in the Java implementation, but it's
simpler to just call the C++ implementation instead.
Center @2x and android banners, and adjust @1x banner to improve
consistency with other resolutions while maintaining sharpness.
Images created by MayImilae
In 5a1a642, I explicitly set android:debuggable="true" for Dolphin.
(By default, it's set for debug builds but not release builds.)
The reason I made the change is because debuggable must be set to
true in order to allow adb backup to be used with apps which target
Android 12. We have no reason to want to stop users from debugging
Dolphin and certainly no reason to stop users from using adb backup
(especially not after forced storage is going to force us to store
the User folder in app-specific external storage!), but,
it turns out that setting debuggable to true is forbidden by
Google Play "for security reasons". Go figure. The beta build
which was tagged earlier today was rejected because of this.
I think the AArch64 JIT has come far enough that it doesn't have to
be called experimental anymore.
I'm also labeling the x86-64 JIT as x86-64 for consistence with the
AArch64 JIT. This will especially be helpful if we start supporting
AArch64 on macOS, as AArch64 macOS can run both the x86-64 JIT and
the AArch64 JIT depending on whether you enable Rosetta 2.
We don't actually need to do this until we bump targetSdkVersion
to Android 12 (which we can't do yet since we're not compatible
with scoped storage), but I figured I'd get it out of the way early.
Not tested on Android 12, but tested to not break stuff on Android 10.
Many Android users want to disable SyncOnSkipIdle as a performance
hack, to the point where it's often suggested as something to
paste into Dolphin.ini (if not to use a fork). If adding it as
a setting in the GUI gives us an opportunity to explain what the
setting actually does and stops people from pasting stuff they
don't understand into INI files, I think it can be worth adding
despite how it can make games unstable. It not being in the GUI
doesn't seem to be stopping people from disabling it anyway.
The added setting in the GUI is a three-way setting called
"Synchronize GPU Thread" with the following alternatives:
"Never": SyncGPU = False, SyncOnIdleSkip = False
"On Idle Skipping": SyncGPU = False, SyncOnIdleSkip = True
"Always": SyncGPU = True, SyncOnIdleSkip = True
See PR 8203 for background on the game INI deletion prompt.
It's been almost two years since PR 8203 was merged, so you
would think that people are no longer creating game INIs that
contain a copy of every global setting, right? Unfortunately,
MMJ was forked not too long before that and never backported the
change, so right now there's a not insignificant number of people
online posting game INIs full of this garbage for others to use.
One thing that's been missing from the game INI deletion prompt
is a description of what the problem with having tons of extra
lines in a game INI actually is. This change adds that, in the
the hope that it will make people ignore the warning less often.
This option does in fact not enable and disable logging as a whole.
You can get logs through logcat regardless of this setting.
Also taking the opportunity to remove the reference to
the "dolphin-emu" folder name since we will no longer be
using that folder once scoped storage is applied to Dolphin.
GameFileCacheService.startRescan (in MainPresenter.onResume)
does nothing if called before GameFileCacheService.startLoad.
Fixes a 3f71c36 regression where already added games would not
show up after app launch under specific circumstances.
Unfortunately the loading indicator still doesn't show up
during a rescan initiated by app launch, but that would
be more annoying to fix, so I will leave it for now.
We want to save the currently selected platform tab,
but doing so immediately after switching tabs leads to
unnecessarily much file I/O (on the main thread, no less).
This change makes us defer the saving until later.
In master, the game scanning process looks like this:
1. Scan for games
2. Scan for additional metadata (icon.png and meta.xml)
3. Save the cache if needed
4. Update the game list with the results
This change makes the game scanning process look like this:
1. Scan for games
2. Update the game list with the results
3. Scan for additional metadata (icon.png and meta.xml)
4. Update the game list with the results
5. Save the cache if needed
Updating the game list as soon as possible means the user
has to wait less before their games show up. The new behavior
matches what DolphinWX did before it was removed. (DolphinQt
has an even fancier approach where games get added one by one.)
The main reason why I'm adding this isn't actually to allow
users to swipe down to refresh, it's to add a loading indicator.
Considering that the Storage Access Framework can be slow for
folders with many items (many subfolders?), not showing a
loading indicator might give users the impression that adding
a folder resulted in nothing happening even though Dolphin is
scanning for games in the background. But I suppose letting
users swipe down to refresh is a nice bonus with the change.
Léo Lam