Replace winit with raw-window-handle

[MarijnS95]

Preface

This requirement came up while attempting to support Android Surfaces in "regular" apps that may not be backed by winit. Separately it also came up while temporarily replacing the old android_glue code with ndk-glue; winit doesn't provide an "Android window handle" through the Ext trait "system" similar to Windows/X11/Wayland, requiring the use of ndk-glue.
However, winit does provide this Android handle, as well as all other handles, directly through a generic RawWindowHandle - which has been used now to prevent pulling in another dependency to get access to static resources.

A head-start with this conversion for Android and Wayland can be found at https://github.com/MarijnS95/glutin/compare/raw-window-handle.

Why RawWindowHandle?

It exists solely to decouple surface/window consumers from winit-specific code (window "producer"), and allowing others (other crates) to interoperate with rendering-API crates easily. On Android it allows working with arbitrary Surfaces anywhere in an an app's View.

What's not available through RawWindowHandle?

They don't provide any info about the window itself, there's no inner_size(): this'll be up to the user to pass in.

What to do with WindowedContext?

There's no Window to hold on to anymore (RawWindowHandle doesn't have any lifetime guarantees). Perhaps it's best to remove it in its entirety, moving all functions on it to Context<>? Alternatively we can "keep" it and just use RawWindowHandle for the W type, in case it starts doing lifetime juggling at some point in time.

headless/surfaceless?

I'm not fully understanding what is going on here. It seems that these features require a connection to windowing system? I thought that wasn't needed at all, but it seems to be "hacked together" with hidden winit windows on some occasions. What's there to salvage from this code if the goal is to drop winit entirely?

Using winit helpers

It seems that at least the x11 backend leans on winit to call xlib functions: these'll need to find another place if they need to be called at all.

Retaining winit behind a feature flag

It can still be useful to provide the user with e.g. an event-loop helper function (to listen to Suspended/Resumed events on Android for surface creation/destruction, and forward Resized to fn resized()).

---

All in all this seems like a rather large refactor, one that may need to be done in smaller iterations to get right. For one we could introduce RawWindowHandle support in the public API first, then migrate internal functions (that build winit windows) over to the new RawWindowHandle API, and finally deprecate/remove or hide winit functions behind a feature flag.

I probably forgot a million things, and mentioned many things that I could easily look up myself, but felt the need to bring this up first for discussion before really making any more progress on the aforementioned WIP branch.

[kchibisov]

I agree and I've already started working on it. I'll probably send a PR based on old v0.23 rework and some ideas I've got while reading through out the egl/glx spec.

Basically we need like 4 core structs.

Display, Config, Surface, Context.

And display is the one that can create the rest of 3. Surface will require Config, Display, and optionally RawWindowHandle, and probably Context.

There should be a way to find arbitrary configurations and pick the suitable one, like ConfigFinder from v0.23 branch.

I'm not yet sure about adding support for pixmaps and pbuffers, given those are X11/Windows specific.

In general it's not that hard to decouple glutin from winit, it would just mean to rewrite it, given that its current internal state is unmaintainable...

[MarijnS95]

@kchibisov Great, thanks, and I'm glad you're taking over as I wouldn't have done much more than trying to change the current API to accept RawWindowHandle as I don't have a need for this myself (don't use OpenGL, don't have much experience with it, but as said before, got "committed" to resolve all the Android issues so that android-ndk-rs/winit stop being flooded with dubious contributions).

You're right that the current internal state is very tricky to work this into, glad that you've got a plan for this and let me know if there's anything to help out with (on the Android side) 👍

IIUC:

• Display: Connection to a windowing system (i.e. through EGL);
• Context: OpenGL context, with the notcurrent/maybecurrent system;
• Surface: Thing to render to, possibly created from RawWindowHandle or maybe something offscreen if supported one way or another?

I thought PBuffers were "generic", they are used on Android for "screen-less" rendering - but maybe also require a connection to the framework.

As for those who want RawWindowHandle support right now, they can defer to my branch until you publish the first draft of these improvements - or we can bolt RawWindowHandle support onto the current state if that takes a while.

[kchibisov]

Fixed in #1435.