Any examples of using Glutin to create a single context that may be used with multiple windows over its lifetime.

[rib]

Hi, I'm trying to update egui/eframe to better support Android by lazily creating graphics state when applications first resume and on android it would destroy and recreate surface state when the application is Paused and Resumed.

I've been able to get egui/eframe working like this on Android when running with wgpu and the same should be possible with gles + egl but I'm currently not really clear on how I can do this with the Glutin API.

My impression is that Glutin tightly couples GL contexts with windows which seems surprising to me, and I'm unsure at the moment how to practically create a context that's initially not associated with any windows/surfaces and then separately be able to create and destroy windows to use with that context. It would also be OK if the context is initially created with an associated window but I'd still like to be able to freely destroy and create other windows later that would be used with the original context that shouldn't need to be destroyed.

Ideally I'm also looking for an approach that will work consistently across platforms; avoiding the need to handle Android as a special case. (So if possible I'd like to avoid needing to create a RawContext type of escape hatch just for Android)

A few things I have seen:

I've seen that a window can be "split" from a glutin context but also saw the surprising safety warning that if the window is destroyed then the context should be destroyed first which I found counter intuitive. I also haven't seen how you can do the opposite and attach a window to a context. I think I would have expected that Context::make_current() would have taken some form of WindowSurface argument that would allow contexts and window surfaces to be managed separately.

I've seen the multiwindow example which isn't quite what I'm looking for here since that seems to create a separate context for each window which shouldn't be necessary here (and also implies re-creating GL state, such as uploading textures which isn't desirable).

I've also seen the rawcontext type that represents a context that's associated with a window that was created externally which doesn't seem applicable. In this case I'd still like Glutin to handle creating window surfaces.

In the Context docs I see it says "however Contexts can be shared between multiple windows" which does suggest that it is possible to do what I'm looking for so maybe I'm currently just missing a trick somewhere?

Maybe there's even some example app somewhere that shows how this kind of use case can be handled?

Any pointers would be much appreciated!

[kchibisov]

See #1435.

[rib]

See #1435.

Ah perfect! Yeah that looks a lot more like I was hoping to find, with the addition of the separate Surface API and then passing a surface to make_current - looks good.

[kchibisov]

I haven't tested android on it, but I'd assume that it won't work because I use platform function to create surface. Should adjust it to check if it's present or not, but don't have time for that.

Though, I'm open to patches for that PR.

[rib]

okey, yeah, no worries. I expect adding the Android EGL support should be pretty easy in general, and it doesn't sound like a big deal if it's not initially supported. Maybe I can send a patch for Android at some point if no one else gets there first.

It's also not really a high priority for me while I'm not using Glutin myself but since I was looking at updating eframe + wgpu to work on Android I at least can't break the glow/glutin backend, and this change certainly looks like it would make it practical to support surface management similar to wgpu.

[kchibisov]

I expect adding the Android EGL support should be pretty easy in general

I think around ~20 lines of code, given that I use just function that will likely fail on android. But I don't have an ability to test. I'll get to it at some point, just can't test.

[rib]

yeah, if you end up making the changes blind I'd probably be able to test that easily enough.

I'll keep in mind creating a minimal glutin + winit example in my android-activity repo to smoke test your branch.

[kchibisov]

Done in #1435, but no example yet...