Initializing GraphicsWindow layout & children requires cooperation from
the graphics stack: on my system, for example, it causes a Vulkan
context to get created in order to get driver info. This is a slow
operation, and right now it is taking about 60-70% of the Dolphin
startup time on my system.
Move instead to a lazy-initialization model where the constructor
does nothing, instead offloading work to a separate Initialize() method
called before the window is shown.
I would expect this should be done for other larger parts of the UI,
especially the ones where creating widgets ends up triggering large IO
subsystems (I suspect controller configuration might be doing that).
(I'm not super happy with how this is implemented, but right now it's a
one-off, and it's a major complaint users have with the new UI. I
prioritized getting something working quickly...)
Thin archives contain pathnames pointing to the object files instead of
full copies of the object files. This significantly reduces the disk
usage when building Dolphin.
Size of *.a files: (gcc-8.1.0, Linux amd64)
- Before: 83,876 KB
- After: 1,876 KB
- Diff: -82,000 KB
The resulting binaries are the same as before.
A similar change was implemented in the Linux kernel v4.8:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a5967db9af51a84f5e181600954714a9e4c69f1f
Now the detection heuristic has changed, the old value is no longer
valid.
Some example thresholds for known mipmap effects that should trigger:
SMG's lava has a mimimum difference of ~17.8, SMG2's clouds have a
minimum difference of ~14.8, and Wind Waker's foam has a minimum
difference of ~15
Non-triggering examples were tested and all had a calculated difference
lower than 3.
So a value of 14 should lean towards false-negatives instead of
positives, but this is clearly incomplete testing and may require
further tweaks later.
This no longer converts from sRGB to linear for the reference mip
downsample - even if the original mipmap creation tool used an sRGB
colorspace (which isn't really guaranteed, and may even change per
game), this is a "fast" heuristic that's only an estimate anyway.
The average diff is also now stored in a u64, avoiding floating point
calculations in the per-pixel hot loop.
This should speed up the detection significantly, hopefully fixing
jank when loading in new textures.
Since we don't have proper confuguration file of what to include/exclude
in the backup, this better be disabled because it will lead to unexpected
state. This will solve any issue that was keep hapenning even after fresh
install of the emulator until you manually clear the app data.
Before we used different way of identifying which settings menu to
show, someotimes we used the section name, other times we used the
settings file name. This one replaces all those different ways by just
one way based on a menu tag which is more clear and easy to follow.
This will avoid effects being unexpectedly broken in these games if the user disables the option globally. This list is by no means comprehensive, these are just the games I could confirm use custom mipmaps.
Normally, SI is polled at a rate defined by the game, and we have to send the pad state to other clients on every poll or else we'll desync. This can result in fairly high bandwidth usage, especially with multiple controllers, mostly due to UDP/IP overhead.
This change introduces an option to reduce the SI poll rate to once per frame, which may introduce up to one frame of additional latency, but will reduce bandwidth usage substantially, which is useful for users on very slow internet connections.
Polling SI less frequently than the game asked for did not seem to cause any problems in my testing, so this should be perfectly safe to do.
spycrab