Feedback: Threading and API handling

[ShizZy]

Looking for some feedback on a couple of development items:

Currently, we are currently using 2 processing threads
1. Emu core (PPC core + main window)
2. Video core v2.0

I’m considering whether or not we should split the emu core thread up into 2 threads, effectively giving the PPC core its own thread. I’m thinking this may give a minor speed boost (the PPC should really have one cpu core devoted to it fully), and it might make the emu a little more responsive, smooth, etc. Not sure though if this would just make things more complicated – Thoughts?

Currently, we have an interface “EmuWindow” for seamlessly supporting multiple window systems for the GUI frontend. We also have the “InputCommon” interface for supporting multiple control devices (e.g. keyboard, joypad) for emulating GC controllers. However making these separate means we need some mechanism for getting input from the EmuWindow API to the InputCommon API when they aren’t the same (which is often always). This raises the following questions:

• How can we simplify this?
• Should EmuWindow contain methods for getting keyboard input from the window to pass on to a InputCommon? Right now we hardcode Qt hooks into the SDL input plugins, this kind of defeats the purpose of the whole system IMO
• OR should we always add EmuWindow and InputCommon instances in pairs (e.g. EmuWindowSDL and InputCommonSDL, EmuWindowQt and InputCommonWt, etc) and make just the Input/Output IO selectable? (e.g. “run using Qt” or “run using SDL” etc.) – This method also has some big limitations.
  

What do you guys think?

[neobrain]

- we should be able to just use SDL for input no matter what EmuWindow impl is used. Just need to find a way to tell Qt to let SDL grab input for the render window
- Seriously, we don't want to use Qt (or any other GUI library) for emulation input...
- Currently, GUI frontends are expected to start their own thread (and gekko-qt actually does that). I see no problem with that, since there's no real reason for gekko-cli to spawn some kind of "idle thread" in addition to the ppc thread. If anything, we might want to add some ppc_on_thread parameter to core::start/init/whatever.

---

Meh, just looked around for an hour or something. I was told on IRC that it's not Qt's fault that we didn't receive any input from SDL back when we tested it. Further investigation yielded that we probably need to use SDL_CreateWindowFrom which takes a native window handle (.. this is exposed by any Qt widget) and creates an SDL_Window object from that (without actually creating yet another window). This will override Qt's event handler and use the SDL one instead, allowing SDL to catch input events.

[ShizZy]

Thanks for the feedback. So in summary:

- Keep InputCommon implementations segregated from the GUI API
- Input libraries will need to support that (e.g. SDL2), so we'll need to update InputCommon to take a reference to the current EmuWindow and "do the right thing"
- As far as CPU is concerned, I am still not sure what the right thing to do is - I am fine with the frontend making its own GUI thread. However, currently the frontends run the CPU loop (which IMO is kind of silly). It seems to be like the only "right" solution would be for the frontends to launch two threads, one for handling themselves (GUI etc) and another to simply call the core::run(), which doesn't return until the game has ended.

Thoughts?

[neobrain]

- EmuWindow needs an additional method called "GetNativeWindowHandle" or something, that's what SDL2 needs anyway.
- Remember that we also need a way to externally stop core, so some synching mechanism is necessary (if it's not already available).
- Moving the CPU running logic itself to core should be fine. Qt's EmuThread::run would basically boil down to core:run() or sth like that.

[Shonumi]

IIRC, when I dealt with the issue of gekko-qt using SDL for input, joypads were working just fine; it was with keyboards that things got messy. I just bypassed it with a hack, more or less, in sdl_keys. It'd be great if input_common could just override Qt's event handler with SDL, as that simplifies things a lot.

[neobrain]

That's just what SDL_CreateWindowFrom does

[Shonumi]

I know that, I read your post. I'm just saying that would be great if EmuWindow and input_common could handle all of that stuff . I'm giving feedback

[neobrain]

eh nevermind me, I guess

btw Shonumi, if you have a minute could you remove the Qt hacks in input_common when you've got a minute? I'm not quite sure what exactly needs to be killed there without breaking stuff, and I'd like to start with a clean base when actually fixing it.

[Shonumi]

Sure thing. I'll get to it on Friday though, as I'm away from both of my computers right now. iPod's are not great for this kind of software development.

Sorry I haven't really done anything for Gekko in a while. I'll try to step it up when I get back to my computers.

[ShizZy]

Shonumi: No worries, as long as you don't forget us

Anywho, sounds good. I have a whole sloppy mess of changes that I am holding off on committing until I can resolve this stupid bug that's breaking mario/zelda/etc with the new video core. Once I can resolve that, I'm going to merge in all of my changes to master and fix up this window stuff.