Emulator Issues #13055
open
Added by taolas over 1 year ago.
Updated over 1 year ago.
Relates to performance:
No
Relates to maintainability:
No
Description
Host_UpdateDisasmDialog() does not seem to be blockable and causes some problems. The problems appear to originate from PowerPC::RunLoop() sending the signal.
Only appears to trigger when a game is running (not paused).
-
Changing UI Options will trigger RunLoop()'s Host_UpdateDisasmDialog(). A slider will spam it like crazy and causes some lag/issues if there's an open UI element that gets updates from UpdateDisasmDialog (mainly debugger windows). Ex: Open Code Widget. Run game. Adjust graphics slider. Should see the slider lag a bunch and Code Widget spaz out.
-
RunAsCPUThread can trigger RunLoop() as well. I'm not sure if it's every instance, or just UI connected ones. I think they should all be SignalBlocked though. Certain ones are causing undesired behavior from the signal.
The RunLoop's signal is currently required for the register widget to function and certain other debugger stuff to work. Not sure about other UI stuff.
Couldn't figure out how to block it for more tests. The alternative is modifying the signal receivers to discard the signal while a game is running, but I don't think that is ideal.
Small mistake, RegiderWidget doesn't have an EmulationStateChanged slot, so it was relying on UpdateDisasmDialog. Easily fixed.
The RunLoop() code and signal has been there since the beginning. I'm not sure if anyone can be confident on if the signal is still needed there. I'm thinking I should make a PR reviewing if the UpdateDisasmDialog should be updated and removed from RunLoop.
EmulationStateChanged doesn't trigger on breakpoints, which may force the addition of UpdateDisasmDialog in some places. RunLoop's UpdateDisasmDialog takes care of signaling on BPs, but triggers on too much random stuff. There's no obvious place to send a Paused signal on break. Maybe CheckBreakPoints() after the redundant call in jitasm is fixed.
RegisterWidget probably doesn't use EmulationStateChanged because it colors newly changed items, and spamming signals for updates would mess that up.
I think either:
- UpdateDisasmDialog should not be sending signals when EmulationStateChanged does. Allowing them to be used for different things.
or 2. UpdateDisasmDialog should be a more verbose version of EmulationStateChanged, and not have both as slots in the same file.
Either requires fixing RunLoop's spam. I'm not sure I have a wide enough perspective to make a PR on this, at least not without some guidance.
Also available in: Atom
PDF
Updated by 
Updated by Anonymous