Add Child Renderers Support

[SuRGeoNix]

Discussed in #644

^{Originally posted by lrohrmann October 22, 2025}
Hello,

I'm investigationg Flyleaf as an alternative to VLC and ffmpeginteropx and have more a question then an issue: I try to display one stream that is running in a player in two host controls at the same time. With the standard WinUI MediaplayerElement and Mediaplayer this is possible and I try to archive the same with flyleaf. Currently I'm not successfull with that and wondering if it is possible at all or not possible by design. Bakground is an app that should display mutliple runningen video streams as thumbnails and the selected thumbnail should be displayed in a bigger version too.

Thanks for your great work!

Best regards
Lorenz

[SuRGeoNix]

@lrohrmann @signumnova

So what I'm thinking is to use only child swap chains with their own configuration that they will render/present at the same time that the main Player-Renderer does. However, this will not support anything else (is not a player, is not an audio "presenter" either). Another limitation will be that the D3D11 device will be shared (required to avoid copying the frames around) which means that they will need to present at the same available adapter's monitors/outputs. Otherwise, they will probably do another copy there too or it will not even work -no idea, never tested it-.

Let me know your thoughts and then I will see if a new control will be required as well -where the swap chain will render- (probably similar support such as drag move pan, zoom in/out etc.).

[lrohrmann]

@SuRGeoNix

at least for my use case that sounds good enough. I don't need separate player, audio or anything else - it is just about to render the same video content to another surface (eq. assigning a mediaplayer to two different FlyleafHost controls) , and as far as I understand this is exactly what a child swap chain would do.

[signumnova]

From my point of view the main thing needed would be to still have scaling support on individual 'child' windows. Architecture wise, it would probably need the concept of the "player" to be separated from the "window" so that you can associate one player with multiple windows or output surfaces. Take your point about the limitation around the surfaces having to be linked to the same GPU to avoid copying, (Even though there are cases I have where I would accept that tradeoff if it did have to happen).