Migrate to pyglet>2

[Fat-Zer]

Since most of distributions don't package pyglet-1.5 anymore the lack of support for pyglet-2+ prevents printrun's packaging as well.

All in all it would be nice to migrate to pyglet-2+.

---

The issue was already partially discussed in #1390.

[Fat-Zer]

I've played around a bit and it looks it is kinda possible to use pyglet-2 with old opengl calls. The only real problem I've encountered is that they replaced opengl errorhandler decorators (before/after), so they don't handle glBegin()/glEnd() in a special way, so I had to set pyglet.options['debug_gl'] = False. Here is a crude proof-of-concept drop-in port. As for now it supports only orthographic projection, but seems to be fine.

As for error handlers in principle we can replace them with our own.

On a positive note it would be pretty easy to have a support for both pyglet iterations. And also it works without disabling shadow_window (#1314; though we should probably do it anyway).

If this solution seems too hacky (I'm myself kinda on the verge here), let me know.

PS: Also as an alternative we could use pyopengl. The only thing we will need to reimplement is our bindings for VBO. Besides that, it will be mostly drop-in replacement.

[neofelis2X]

Ooh, that's actually pretty cool! Nice proof-of-concept. I never considered using .gl_compat because it does not improve the codebase. We would just drag old problems along to pyglet 2. BUT if pyglet1.5 is not packaged on linux distros anymore, then this could be a helpful way to go. As an intermediate solution it might be a quick an dirty way to get pronterface on this platforms again.

I have already invested some work updating all the opengl code and with the end of the year I can finally continue working on it. (Had to do a different project in 2024) So maybe I manage to push a clean migration to pyglet 2.0 in the next few months.

Losing errorhandling only really matters for development. We could release this 'hacky' solution in a separate branch.

As for error handlers in principle we can replace them with our own.

Meh, even more code to maintain ;)

for now it supports only orthographic projection

I assume all the glu-Functions are not available anymore? Perspective Projection can be turned off for now. But gluUnProject is used for camera movement and some stuff. Does panning and rotating the view work?

Also as an alternative we could use pyopengl.

We could do that. My argument against it is, that pyglet seems much better maintained. And pyOpenGL writes on their own website: PyOpenGL 3.x is far slower than PyOpenGL 2.x, and PyOpenGL 2.x was not fast.

Kinda funny. I would prefer to stay with pyglet and also use their modern features in the future.

---

So long story short: If most features of pronterface work, I think we should consider this a as a good intermediate solution.

[DivingDuck]

I tend to the same direction as @neofelis2X for not switching to a entirely new library.

I think the prove of concept as an intermediate solution in a separate branch is a possible solution as long that branch have a limited life time. On the other had, if we would be able to step over to pyglet 2.x in a "short" time frame of perhaps 3 month (?), the effort for a interim version is questionable. Anyway, I'm open for that too.

@rockstorm101, what do you think?

@Fat-Zer , I corrected the title for this issue and add the tag Feature request to it (although I think it isn't the best tag for this...)

[rockstorm101]

Thank you @Fat-Zer for tackling this issue. It's been a long standing issue and a pretty annoying one.

I tend to the same direction as @neofelis2X for not switching to a entirely new library.

I'm more of a back-end guy so in all honesty I lack the knowledge to judge one library over the other. I'll go with whatever you guys think is best. The phrase "pyopengl [...] will be mostly drop-in replacement" sounds like a good point to me, but again I'll be happy with whatever you prefer.

if we would be able to step over to pyglet 2.x in a "short" time frame of perhaps 3 month (?), the effort for a interim version is questionable.

I agree. However, if someone is willing to commit to such effort I would be happy to merge an interim solution now and then merging a "cleaner" solution in 3 months time. As long as it solves an issue without introducing new problems it is essentially a step forward and I think it is a good thing.

[Fat-Zer]

I assume all the glu-Functions are not available anymore?

yes

Perspective Projection can be turned off for now. But gluUnProject is used for camera movement and some stuff. Does panning and rotating the view work?

It wasn't at the moment, but both gluUnProject() and gluProjection() are just tiny strips of linear algebra and are easy to implement (probably slightly slower, but still negligible anyway)... I was just lazy about it... I've pushed replacement for both to the branch.

Losing errorhandling only really matters for development.

Not only, it's also responsible for raising an exception if OpenGL fails, which disables 3D View. But thinking about it, it's actually not that much big of a deal.

We could do that. My argument against it is, that pyglet seems much better maintained. And pyOpenGL writes on their own website: PyOpenGL 3.x is far slower than PyOpenGL 2.x, and PyOpenGL 2.x was not fast.

I was suggesting it in case pronterface were keeping the old OpenGL code for the foreseeable future, but in case we are migrating to the modern one, there is no reason to do so.

Kinda funny. I would prefer to stay with pyglet and also use their modern features in the future.

Note, that you will probably have to be quite picky about which one to use as some of them rely on using pyglet's own window/context classes. You may come up with some adapters to mitigate it, but it won't be possible to you use all of them out of the box.

We could release this 'hacky' solution in a separate branch.

Hm... I don't really like that idea. From a package maintainer standpoint it's very annoying to track branches. If I may, I'd rather comb this down enough so it won't be shameful to commit to master.

So long story short: If most features of pronterface work, I think we should consider this a as a good intermediate solution.

On the other had, if we would be able to step over to pyglet 2.x in a "short" time frame of perhaps 3 month (?), the effort for a interim version is questionable.

The more I think about this now, the more I inclined towards the idea that it'd be actually better to go ahead with actual migration to modern opengl right away.

I want to take a shot at this myself. If I won't come up with something reasonable in a week I'll prettify this one.

[DivingDuck]

The more I think about this now, the more I inclined towards the idea that it'd be actually better to go ahead with actual migration to modern opengl right away.

I'm in preparation for getting Pronterface running on Python 3.12 and 3.13 w/o compiling warnings and errors. For Python 3.12 there is now everything ready and there is only a warning left for pyglet 1.5.29, but this is no problem. For Python 3.13 it is different as pyglet 1.5.29 wont compile and generate some errors what ends in not having a 3D view available. In the end this python version is quite new and not less libraries still have some quirks to solve, that may be fixed some when in the future, but the way should be to step-up to pyglet 2.x as the old version become more and more a show stopper.

So I appreciate any help from developers who are able to modernize this part in Pronterface.

[neofelis2X]

but both gluUnProject() and gluProjection() are just tiny strips of linear algebra and are easy to implement

Right, numpy is the way.

Note, that you will probably have to be quite picky about which one to use as some of them rely on using pyglet's own window/context classes.

pyglets vertexlists and Batch used to work without the windows, which was mainly what I meant.

I want to take a shot at this myself. If I won't come up with something reasonable in a week I'll prettify this one.

Great, if you want you can take a look at this branch where I already simplified some things, extracted actors, camera class, etc.