Smithay
Migrate gles2 renderer to glow
glow provides a lot of nice things we can use.
glow provides newtypes for gl objects with names. This means glow::Shader instead of GLuint everywhere.
glow also handles common things such as converting Strings and accessing specific properties like a shader's compile status.
Played around with it for a minute and this is what compile_shader looks like when glowified:
unsafe fn compile_shader(
context: &glow::Context,
variant: u32,
src: &'static str,
) -> Result<glow::Shader, Gles2Error> {
// FIXME: Handle this error
let shader = context.create_shader(variant).expect("Zeroed name");
context.shader_source(shader, shader);
context.compile_shader(shader);
if !context.get_shader_compile_status(shader) {
context.delete_shader(shader);
return Err(Gles2Error::ShaderCompileError(src));
}
Ok(shader)
}
- Does glow allow us the generate GL bindings for additional extensions?
- Does glow allow us to target OpenGL ES 2.0?
- Does using glow inside smithay force users of the Gles2Renderer::with_context function to use glow as well?
glow only covers GL(ES), EGL would need its generated code still. It appears GL extensions would need to be manually done.
glow can target gles2. wgpu folks use it for their gles backend. However it appears the barrier between what is and isn't gles2 is quite fuzzy.
The context provided in with_context is just the EGL context and whatever getProcAddress is?
I don't think that switching to glow makes that much sense. Sure, it's nice to depends on external crate which handles unsafe FFI operations for you, but glow is quite heavy as in, bundles a lot of unnecessary code such as WebGL which will never be used in smithay. If you really want to switch to glow, that will require contributing all necessary code related to EGL and required extensions. At the end, it just makes more problems than actually solves compared to internal FFI.
First of all Glow is not heavy in any way, it is super tin and unsafe wrapper, and equity light WebGL code does not get compiled anyway, so who cares. As for contributing to glow, I doubt niche Wayland specific extensions have a place in it, you would most likely just call them manually.
That being said, as it was discussed with Drakulix on Matrix a year ago, I would prefer glow to be a user facing API rather than internally used API, Smithay will always have to use Wayland specific extensions, so it probably makes sense to just call everything manually.
Although I would love to be proven wrong with a POC implementation, as I would prefer to work with glow as well.
Well I'd argue this wasn't really fixed. The question was related more to gles2 renderer using glow under the hood vs exposing it to users.
The original issue: yes. But I was under the assumption, that we can to the conclusion, that we didn't really want to use glow for the backend code, no?