Why should I prefer zengl over moderngl?

[bolducke]

Hi!

I saw that you were also the main developer of ModernGL. I was wondering what was the main reasons one should prefer zengl over moderngl outside of its simplicity.

[szabolcsdombi]

I hope this helps.

ModernGL

ModernGL was first released around 2016. However it gained not much traction until version 4.x or 5.x and those versions are very different from the previous ones.
The most recent version of moderngl is mostly the same idea as it was in 4.0.0 (2017-05-20).
Since then new features were requested and added. Some of them duplicated existing functionality.

An average ModernGL users does not use these new features.
Instead, they mostly rely on the very basic set of features that were already present in 4.x.
Take textures for example:

program = ctx.program(...)
texture = ctx.texture(...)
model = ctx.simple_vertex_array(...)

program.use()
texture.use()
model.render()

Later samplers were introduced, and were possible to bind independently from textures.
So texture.use() should have been deprecated in favor of sampler objects.
Such a change would not have been welcome.

Same goes for the scope objects.
Scope objects assigned to vertex array objects make the render independent from the global state.
For code that is not written with scopes in my from the start commonly ended up with bugs like this.

vao.scope = ctx.scope(samplers=...)

ctx.enable(DEPTH_TEST)
vao.render()  # depth is not enabled here as the vao.scope has an empty enable only

Yet again the ctx.enable() was not deprecated in favor of the most common use cases.

ModernGL has a lot of features that are probably less reliable than worth using.
There are compute shaders in moderngl, shader subroutines, storage buffers, indirect draw.
This is because the OpenGL API on some systems are not well implemented.
Also there is OpenGL ES that has a bit more restrictions compared to desktop GL.

For ModernGL there were nothing I could do despite I tried it many times.
I consider ModernGL stable as it is. New features are still welcome. Deprecation of old features is unlikely.

ZenGL

I designed ZenGL from zero, based on the experience gained implementing ModernGL.
There were two options I could take. Make a library with the most stable subset of OpenGL or the most recent one.
As it turned out painfully, the most recent one is not reliable, despite OpenGL 4.6 is widely supported, some drivers still have bugs.
So ZenGL uses OpenGL 3.3, 100% compatible with OpenGL ES 3.0, uses the same subset as WebGL 2, hence it also runs in the browser.

Does this mean ModernGL has a better OpenGL supports?

Well, no. Here is why:

ZenGL has no compute shaders, but most of the compute shaders you plan to implement with ModernGL could have been implemented with a fragment shader.
On some old hardware this actually results in faster execution.

ZenGL has no storage buffers, read/write images in shaders, atomic counter, and so on.
Well, you can still use any OpenGL binding and have interoperability with ZenGL.
This already does not sounds like rendering. Did you consider vulkan for it?
I actually tried (twice) to make a vulkan library for such use case.

ZenGL has less vertex and image formats available, but here is the thing: ZenGL uses the same subset of vertex and image formats as WebGPU.
The other types are either slow or not well supported or just implemented with the provided formats anyways.

So using ZenGL you might find no float16x3 for size optimized normal vectors. Adding a bit of padding and using float16x4 is actually way faster.

For a beginner ModernGL might look easier to use and learn.
On the other hand ZenGL actually expects the user to know OpenGL well.

For a seasoned OpenGL developer, ZenGL provides a richer experience mostly due to the self-contained pipelines and internal caching.

The features ModernGL could not have landed in ZenGL.

Self Contained Pipelines

This was actually done in moderngl as scopes. But due to the global state it is not as realiable as I wanted them to be.
ZenGL Pipelines are the proper Scope objects.

Caching

The title is a bit of misleading. Caching here actually means the ability to know what is in use and not to rebind it.
To avoid unnecessary api calls or even worse pipeline flushes.

For example:

Having two ZenGL pipelines with the same global state, rendering the second pipeline does not set the global state.
Having two ZenGL pipelines with the same shader code, rendering the second one does not call glUseProgram().
Having two ZenGL pipelines with just the vertex count, vertex offset or instance count different, rendering the second pipeline adds just another glDraw call.
...

Caching is nothing fancy on the inside.
In hot code it is usually a bitwise check at C level.
It does not compare (in terms of speed) to anything that can be done on the Python side.

Immutable Objects

In ZenGL Pipelines are immutable.
This is an obvious helper in debugging. There is exactly one place to look for the problem.

Does the pipeline render to the wrong framebuffer? -- it was defined when the pipeline was created.
Does the pipeline render with the wrong texture? -- it was defined when the pipeline was created.
...

Error Checking

Self-Contained, Immutable pipelines allows us to actually check if the state is complete:

Having a uniform buffer without a binding is likely an error.
Having an unbound attribute without explicitly bound to nothing is an error.
Having something bound to an inexistent binding slot is an error.
Having duplicate bindings is an error.
...

I really wanted this in ModernGL but is clearly not possible without Self-Contained, Immutable pipelines.

Bottom Line

To pick between ModernGL and ZenGL is mostly the matter of taste.
For simple projects (I would say for most, or all of them) it does not matter much.

Implementing the rendering is mostly the effort of writing shaders, not just how you structure your code.

ZenGL has web support, this is a fairly new thing.
ZenGL works with pyodide and has no performance penalty compared to writing WebGL 2 code directly in JS.

[szabolcsdombi]

To answer your question short:

ZenGL has self-contained immutable pipelines with error checking. Internal caching helps with the number of api calls.
Works in the browsers. Uses only the most reliable subset of OpenGL and with the help of ANGLE it can actually run using DirectX or Vulkan or Metal.

[bolducke]

This is such a great response. Thank you for your time.

Immutable Pipeline

I understand your logic behind Immutable Pipeline, but I fear this design will have the same flaw as Vulkan's bake pipeline. By constructing an immutable pipeline, you need, as the developer, to know every possible combination from the start. This can be quickly unmanageable based on my limited experience in Vulkan.

Is it something that could happen with Zengl? If yes, how would you try to overcome this drawback?

For example, if you need to resize your viewport, you now need to recreate every pipeline.

[szabolcsdombi]

Indeed I missed to add the exceptions.

The viewport, raw uniform values, vertex/index count, vertex offset, instance count are part of the dynamic state in ZenGL.

pipeline.viewport = (0, 0, w, h)

you can even bind these values to a memoryview. for multiple pipelines you can have a single piece of memory holding the viewport values.

ZenGL objects are actually lightweight. you can have a builder function to avoid the problem knowing all the combination ahead of time:

def make_pipeline(ctx, texture, **material_info):
    return ctx.pipeline(
        vertex_shader='...',
        fragment_shader='...',
        layout=...,
        resources=[
            { ... texture goes here },
        ],
        uniforms=material_info,
    )

early in the prototyping phase i often have a pipeline builder function like the one above.

---

not used pipelines can be released.

also please note that the vertex_shader, and fragment_shader code was passed as a string in the make_pipeline. due to the caching it won't be compiled N times just once the first time.

[bolducke]

Thank you once more! I think you should put a link on the main readme so that others can evaluate the tradeoff between the two.

[szabolcsdombi]

Thank you, I will

[pbk0]

Would like to see zengl-window similar to moderngl-window
Especially want support for pyimgui as here