@kvark I've got a quick question about EGL, which is used by surfman for X11. I'm using a container for my dev environment because I'm not root on my build machine, and the surfman examples run fine inside the container where I've got all kinds of dev libraries installed and such. Outside of the container, though, the examples bomb out when creating the surfman X11 connection with an error: egl function was not loaded.

Do you know what needs to be installed on the host to get EGL to load?

Probably libegl1-mesa package?

Strangely, I have that and it still won't work anyway. Oh, well, thanks for the hint. I'm not going to worry too much about it . I just needed it for the debugger to work, but I'll be fine without it for now.

OK, so I've gotten your changes to surfman pulled locally and I've gotten all setup to work on the gfx-backend-gl. I just wanted to make sure that this sounds right on how we organize the sharing between contexts because I can't remember exactly how we were going to put it together:

• When you create the Instance ( currently actually when we enumerate adapters ) we will want to create essentially a "root" context.
• The root context is the one that we create here. That is the context that we use to create the gl container with the from_fn_proc function.
• When surfaces are created for that Instance, each surface will create its own context that will have the "root" context in the share_with of its ContextAttributes.

Is that along the right lines?

OK, so I've gotten your changes to surfman pulled locally

My changes were merged into surfman proper in servo/surfman#185, you shouldn't need my branch, just use master.

Is that along the right lines?

Correct!

Also, the adapters may need to create their own GL contexts, depending on exposed/requested features. If you expose only a single adapter, you can just re-use the context from the instance, that's simpler.

Haha! Finally got this working I think!

I haven't switched to using the official servo/surfman yet. I'm using a fork of @kvark's old fork 'cause I got stuck without internet for a few days and it was what I had on my machine. 😉

I also started work on porting WGPU to the latest GFX and including support for OpenGL and it is going very well so far. Hope to have this finished soon!

OK, I think this is good now. ( Pending CI ).

Seems to be working on macOS. Although, we'd need to test the wgpu-rs samples before publishing the gfx backend.

Seems to be working on macOS.

Oh, sweet.

Although, we'd need to test the wgpu-rs samples before publishing the gfx backend.

Yeah, sounds like a good idea. That was the issue last time: we didn't find the issues with the backend until we tried hooking it up to WGPU.

Nice to have a near-instant CI now, isn't it? :)

Uh, yeah, that's pretty nice. :)

If I've estimated correctly I should be able to test this with WGPU very soon. I'll have a PR on WGPU and we'll figure out how well this works with the WGPU examples.

Please rebase and squash

Done. And, hey, we deleted more lines of code than we added. 🎉

Ah, oops, I made the GL backend only included in the examples for cfg(unix) platforms and now CI is failing for windows. Do we want to completely disable OpenGL for windows, or do we leave it? I don't think I broke GL on windows with the surfman stuff, but I never tested it before or after so I don't know if it's working.

Let's disable it on Windows completely

that also means we don't need to enable WGL dependency

Build succeeded:

• Android Stable
• iOS Stable
• MacOS Nightly
• MacOS Stable
• Ubuntu Nightly
• Ubuntu Stable
• Windows Nightly
• Windows Stable

Yay! 🎉 Thanks so much for your help @kvark. Couldn't have done it without your guidance. 😄

Next up, WGPU!