[vlc-devel] [PATCH 0/6] Allow the vout_window implementation to suspend rendering

[Alexandre Janniaux]

Hi,

Thank you for review!

On Fri, Feb 05, 2021 at 11:34:59AM +0200, Rémi Denis-Courmont wrote:
> Le perjantaina 5. helmikuuta 2021, 11.01.51 EET Alexandre Janniaux a écrit :
> > This patchset enables the vout_window implementation to suspend
> > the rendering with the vout_display. This is primarily designed
> > for iOS where the application can be moved to the background and
> > should not submit any draw commands from there, but it should
> > also match other cases where the application can stop doing the
> > rendering,
>
> This is currently handled entirely within the display plugins, which has the
> disadvantage that it can't skip filters and conversions, but has the advantage
> that, well, it's implemented.

Indeed, it was handled by ios.m previously, though not
correctly, so back then it could have skipped prepare
and display.

I'm not sure we can completely skip filters, because of
deinterlacing, but maybe we can tag the filters with the
capability to handle picture skipping.

> > for instance because the application is not visible
> > anymore, and thus should also be usable in cases like Wayland.
>
> I doubt that this would work for Wayland as is. I would expect that tthe
> window provider needs to acknowledge the rendering resumption request from the
> display server, and that it should only do so whence a picture is rendered.

Indeed, I had written that it probably needed additional
feedback because of this acknowledgement in the first
cover letter, that got deleted by send-email. Wayland also
needs that kind of mechanism for the current race reported,
but I haven't tackled this because of the additional threading
problems it could create and hope we can solve this during a
meeting someday.

> But here, the callback returns immediately, regardless of the progress (or
> rather the lack thereof) by the video output thread.

Do you think that the callback should be blocking until the
first frame is displayed here? I'm not sure it can superseed
the additonal feedback mentioned above or not for wayland and
haven't checked with other window providers, but I have no
issues with this on the iOS/tvOS/MacOSX side. Asynchronous
signalling to the vout_window would work too since I can
synchronize internally but I'm not sure how to make the API
non-confusing.

In this patchset, there's still an existing issue with the
display startup, since we'll start the display anyway and
there is no way to defer it because of the format negociation.
I'm not sure how much of an issue it is on the iOS side, but
it's currently handled by blocking on the first MakeCurrent.

I've also not handled the initial state in the window module,
because of this case and because it is already handled
differently, but it should probably be fixed eventually.
I just fear usual deadlock issues between opengl module
creation and main thread / window thread so I planned to try
moving them later.

Regards,
--
Alexandre Janniaux
Videolabs

> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel