DolphinQt: Reduce latency of TAS input's controller input passthrough

[JosJuice]

Fixes https://bugs.dolphin-emu.org/issues/12676.

Needs testing to see if this impacts performance when controller inputs are changing.

[leoetlino]

How feasible would it be to wrap the entire series of GetButton calls in e.g. GCTASInputWindow::GetValues inside QueueOnObject instead of queuing every UI control update one by one? Seems less expensive than constructing so many dummy QObject and connections and locking/unlocking dozens of times.

Considering GCTASInputWindow::GetValues and WiiTASInputWindow::GetValues already call Qt functions — which is probably not thread safe — maybe we should just wrap the call to GetValues with QueueOnObject?

[JosJuice]

I would prefer to avoid making large changes to this system until PR #9624 has been merged (or closed without being merged), since that PR changes the surrounding code quite a bit.

Regarding the performance, doing it the way we're currently doing it does mean that there is zero cost on frames where none of the inputs have changed, but a bigger cost the greater the number of changed inputs is. I'm not sure if we want to pay the cost of one blocking cross-thread call even on frames where no inputs are changed. I especially wouldn't want us to pay the cost before calling isVisible, since that would force us to pay the cost regardless of whether the user actually is using TAS input. But you are right in that calling getters on Qt widgets isn't actually thread-safe...

[leoetlino]

Hm, I guess this is probably fine as a temporary solution...

The fact we are calling Qt functions (and not just getters either) from the wrong thread is still highly problematic, but at first glance #9624 seems to fix that.