[FernetMenta]

The next step to a better video player is to separate rendering from the main thread. This is necessary and has many advantages:

- Smooth playback even if the main thread is hijacked by addons or work intensive tasks
- Prevent from lots of deadlocks
- Further step to componentise VideoPlayer and make it independent from application
- Finally have a proper headless Kodi
- ....

[Paxxi]

+100.

Can you share some rough design so we have an idea of what your vision is?

I've been thinking rendering runs one thread and something like inputmanager runs the UI-thread/input/messaging. Is this along the lines you're thinking or am I totally wrong?

[FernetMenta]

Yes, you are right. Basically I want to move FrameMove and Render out of CApplication. MessagePump should stay there. We may need to split AppMessenger because some messages are supposed to be executed by the render thread.
I expect some tricky and weird things coming up to surface when input and rendering interfere

EDIT: MessagePump needs to be driven by the render thread. Then we need to make CApplication::OnEvent asnyc, so that the render thread can deliver the events to the input thread to be executed.

[popcornmix]

+1
Currently on Pi2 the first subtitle that appears causes a noticeable video stutter as font rendering is done on the main thread.
There are other cases such as loading the OSD dialog for the first time causes video to stutter.

Just to be clear, which thread will be attached to the GL context? Still application, or will this be moved to a dedicated thread?

[FernetMenta]

Just to be clear, which thread will be attached to the GL context? Still application, or will this be moved to a dedicated thread?

I intend to spawn a dedicated render thread in windowing, this already owns the gl/gles context

[Paxxi]

We can have several message pumps and have everything go through appmessenger. We just have to queue messages into different queues or flag messages so they're only visible the correct message pump.

We already have some of this today with the handling of GUIMessage.

[FernetMenta]

@Paxxi could you define such an interface? How do you want windowing deliver messages to app?

[Paxxi]

I haven't had time to think this through fully but basically we use the same interface as we have now for sending using sendmsg/postmsg.

Not sure if we should limit ourselves internally to a certain amount of queues to keep it simple or basically have a vector of queues so we can extend it if need arises.

Easiest filtering is to continue on the current path where we filter by receiver such as MESSAGE_MASK_WINDOWMANAGER.

Retrieving messages need to be rewritten a bit so the thread calls ProcessMessages(MESSAGE_MASK_WINDOWMANAGER) to process that specific queue.

That's the rough idea I have, I bet I'm missing some details that will need to be fixed for it to work.

[FernetMenta]

I started work here: https://github.com/FernetMenta/xbmc/tree/renderthread

May take a while until this will result in something executable. I have to fight against lots of evil globals like: g_graphicsContext, g_Windowing, g_WindowManager, g_application, etc.

[natethomas]

Sorry to ask this so late, but I'd been kind of wrapped up in devcon planning, so I missed this. It seems as though the biggest (or at least a big) potential benefit of going down this road is always on video for PVR users, making for an appliance-like setup more consistent with more traditional DVRs. Is that a reasonable expectation for this work?

[FernetMenta]

I consider it as a key step to get Kodi to the next level. Long desired headless becomes true. VideoPlayer infrastructure can be used for transcoding. Kodi's architechtue is more than 15 years behind. Combining main thread and gui rendering is old school mfc style of the 90s. I posted this in VideoPlayer section but this is more important then video player. Without this step Kodi will die.

[da-anda]

thanks for working on this Rainer. How far did you plan to go with this? I suppose a full decoupling of GUI and core would be a too big task in one go? With decoupling I mean that core only uses some sort of messaging/signal/event system to communicate with a self-contained GUI component.

[FernetMenta]

core is not the problem here. The problem is the pest of globals that makes everything dependent on everything. Instead of avoiding it I see this anti pattern of singleton spreading out like cancer. Take a look as CSplash that resides in utils and is (guess what) a global.
https://github.com/xbmc/xbmc/blob/f42c66...sh.cpp#L41

g_application gets the instance of CSplash and calls Show(). It instantiates a class from guilib and renders it making use of g_graphicsContext and g_Windowing.
The only reasonable thing to do here is dropping CSplash completely and build something new in rendereing. At this time I can tell how many of those issues I need to resolve.

[Kib]

In this context I believe this is interesting as well ? http://forum.kodi.tv/showthread.php?tid=241228

[FernetMenta]

In this context I believe this is interesting as well ? http://forum.kodi.tv/showthread.php?tid=241228

Absolutely, I thought about linking this too. That post shows how alarming the current situation is. I hope everybody is aware of this and helps getting rid of globals/singletons.