examples/glupload: Upgrade to `glutin 0.31`
Fixes #428 (closed)
Glutin completely detached from winit in the 0.30 upgrade, concerning itself exclusively with OpenGL and WSI APIs around it and leaving any windowing system interop to the raw-window-handle crate specifically designed for this purpose.
This untanglement massively cleans up and simplifies the glutin codebase, and expands on surfaceless rendering as well as drawing to simple views (textures) on the screen as is common on Android, without having control over the entire "window" and event loop.
Some winit boilerplate is however still provided as part of the glutin-winit crate. Most of the glutin+winit flow in this glupload example is adopted from glutin's example, following platform-specific initialization sequences that heavily clutter the code (only creating a window upfront on Windows, only forcing transparency on macOS, and trying various fallback attributes to create a context).
At the same time winit's Event::Resumed and Event::Suspended event strategy is adopted: this event was previously for Android and iOS exclusively - where window handles come and go at the merit of the OS, rather than existing for the lifetime of the application - but is now emitted on all platforms for consistency. A Surface (via RawWindowHandle) is only available and usable after Event::Resumed, where we can create a GL surface and "current" the context on that surface for rendering. This is where the GstPipeline will be set to Playing so that data starts flowing. The inverse should happen in Event::Suspended where the Surface has to be given up again after un-currenting, before giving control back to the OS to free the rest of the resources. This will however be implemented when Android is brought online for these examples.
Finally, now that the gst-gl-egl and gst-gl-x11 features turn on the relevant features in glutin and winit, it is now possible to easily test x11 on Wayland (over XWayland) without even unsetting WAYLAND_DISPLAY, by simply compiling the whole stack without EGL/ Wayland support (on the previous example winit would always default to a Wayland handle, while glupload could only create GstGLDisplayX11).
Note that there is already a working branch
Most notably I'd still like to use this PR to confirm that simply setting State::Paused is enough, and doesn't cause any video content to endlessly pile up until State::Playing? And is shared_context.activate(false) good enough to not cause the GL Elements in the GstPipeline to access or rely on a current context? So far everything runs fine and easily survives Suspended->Resumed pairs (when the phone is locked and unlocked, or the user switches away from the app) but I am not sure if it's working correctly.
Finally, is there any way to check for leaks in the GStreamer objects after a "clean" shutdown of the app, just in case?