LibretroCore depends on getting its input state updated before retro_run() is called. Currently, InputManager is responsible for this. When asked, it'll execute SDL code and read the states of all controllers it's aware of, passing this data down to LibretroCore. Since InputManager lives on the main thread, anything that'll block the main thread will block the entire pipeline from the source, regardless of whether we're using an asynchronous timing source like Looper.
@Druage, what were our plans for offloading the input code to a separate thread while still having input available to QML to control the UI in the future?
LibretroCore
depends on getting its input state updated beforeretro_run()
is called. Currently,InputManager
is responsible for this. When asked, it'll execute SDL code and read the states of all controllers it's aware of, passing this data down toLibretroCore
. SinceInputManager
lives on the main thread, anything that'll block the main thread will block the entire pipeline from the source, regardless of whether we're using an asynchronous timing source likeLooper
.@Druage, what were our plans for offloading the input code to a separate thread while still having input available to QML to control the UI in the future?