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...)
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.
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.
We can just use a vector of a vector, which also has the benefit of
keeping the size accounted for as well, allowing us to get rid of a
count parameter for CodesToHeader().
Instead of using an out-reference, we can modernize these to return the
std::string directly. While we're at it, also remove the unused name
parameter.
Given we now use a base class for the interface, we can make all member
functions, types and constants that aren't directly related to
instructions private.
HID2.LSQE is the Load/store quantize enable bit for non-indexed format
instructions (which are psq_l, psq_lu, psq_st, and psq_stu). If this bit
is not set and any of these instructions are attempted to be executed,
then a program exception is supposed to occur.
This register is defined as "optional reserved" within the aarch64 ABI.
Linux doesn't use it, but we must not modify it on ios or windows.
As we have plenty of registers on aarch64, let's just always skip this one.
This function was duplicated across all the opcode tables: the main info
tables, the interpreter tables, and the x86-64 JIT tables. However, we
can just make the type of the std::array parameter a template type and
get rid of this duplication.
const on a parameter being passed by value in a prototype doesn't actually signify
anything, these are only applicable in the definition, where they make
the opcode parameter immutable.
