Avoid using wrappers over moderngl

[einarf]

In most cases there's really no need to have wrappers over moderngl types. We want people to use moderngl directly. We currently have some minor differences in how certain types are created and still have some lingering cruft from the old resource system.

✅ Textures

Additional helper methods can be delegated to a separate module. These are are things like:

• Drawing a texture or fbo layer a s full screen quad
• Filling a texture with data from PIL/Pillow

Overall because of the resource loading change, we can drop the wrappers completely. This also means we can make a pluggable system for texture loaders if needed. Some might have textures stored in all kinds of formats and should be able to customize this.

✅ Frambuffer

We can drop the whole FBO stack system to eliminate the FBO class completely. We also killed the FBOWindow class, so this transition is fairly simple now. Helper methods drawing layers will be the same situation as textures.

❓ ShaderProgram

This one is more tricky since we currently don't have a way to reload a shader without using a wrapper. We rely on reusing the same Program object. Reloading a shader could also possibly change the attribute binding causing issues for VertexArray because they are paired together on creation. The ability to do this is also closely linked to our VBO class.

Program still have an extra property we can store things in such as the attribute_key used by the VAO class.

It would also be useful if a Program could be assigned a label in moderngl. When errors occur we can display the label to better understand what shader caused the issue.

Auto detection if varyings from the source can still be done in the resource system. You are on your own if shaders are manually created.

The minimal actions would be:

• Provide a callback system for shader reloading so people can update the reference and create a new VertexArray.
• Rename the class to Program and ensure the wrapper matches moderngl.Programexactly, but this is not a desired outcome. This affects performance negatively and should be avoided.

We should probably also create a pluggable system for shader loading so people can customize if needed. There's an ocean of different ways to represent shaders out there.

Possible solutuion: Keep the ShaderProgram class for 2.0 and make it optional.

❓ VAO

The main purpose of this wrapper is to generate new VAOs on the fly matching the incoming ShaderProgram and display anger when the vertex formats don't match. The VAO class could also be optional.

The whole point of the VAO class is not having to juggle around lots of Buffer objects trying to figure out the attribute format for each version generated. Do we have enough information in Program and VertexBuffer alone to still do this in a helper class or module?

Possible solutuion: Keep the VAO class for 2.0 and make it optional.

Types we don't wrap

• Context
• Buffer
• Uniform types
• Texture3D
• TextureCube
• Scope
• Sampler
• ComputeShader
• Query
• ConditionalRenderer

[einarf]

Textures and framebuffers/renderbuffers are no longer wrapped. It's still a bit early to tell what happens to shaders and vaos, but we might just take the leap and do it. Issues can still be sorted upstream for ModernGL.

[einarf]

Mostly done in the 2.0 branch. After some careful consideration it looks like the VAO class will be staying, but it will be optional. Everything is ready to nuke the ShaderProgram wrapper.

[einarf]

This is finally done! 🍰

With the exception of the optional VAO class that really only auto generate a VertexBuffer objects for each unique incoming program in draw(), we are now 100% on moderngl.