Consider splitting the WebGL related code into a separate crate.

[glennw]

Instead, we could connect WebGL up to WR via the ExternalImage APIs, which support CPU-side buffers and native surface handles.

The primary benefits would be:

• Simplify the internals of resource cache by removing the GL context management code.
• Remove the WebGL cargo feature, since not all clients use it.

[kvark]

we could connect WebGL up to WR via the ExternalImage APIs

WebGL needs GL context, while ExternalImage does not. Are you suggesting to read back the WebGL surfaces into CPU memory in order to bring it to WR?

[emilio]

I'm assuming we'd use something like rendering to a native texture, and pass that handle to WR.

[MortimerGoro]

Very good idea, it will simplify a lot of things for WebGL and WebVR.

Could you assign this issue to me? I'd love to work on this ;)

[emilio]

That'd be awesome, please do!

[glennw]

For some reason, GH won't allow me to assign this to you - but that's great if you can work on this!

[MortimerGoro]

Fine, I'll work on this ;)

My first thought is to move WebGL code into a Servo component. It eases development, testability and I don't think that there are use cases to use the component outside Servo. Anyway, it will be a standalone component, so it will be easy to move if required.

It's a good opportunity to work on #607 too. I haven't forgotten about that ;)

For some reason, GH won't allow me to assign this to you - but that's great if you can work on this!

Maybe it´s because I'm not in the Servo organization?

[glennw]

That sounds good to me, and working towards solving #607 would be a great benefit too!