Should support ARM processors on Linux (32 and 64 bit) and Windows.

[Harvie]

Hello,
i've noticed there are precompiled binaries in this repository (eg. libTkgl1.2.so ). Isn't this posing a challenge in multiplatform/multiarch software?

I am developing FOSS software ( https://github.com/vlachoudis/bCNC/ ) that has user base not only on different linux distros, windows and mac, but also on x86-32, x86-64, ARM32 and ARM64 CPU architectures. So i want to be sure this will not break things for anyone... On all thos platforms we currently install bCNC including all dependencies completely through pip, is that still achievable when using tkinter-gl? Some of the users are woodworkers rather than programmers, so we cannot really force them to compile something manualy :-)

[NathanDunfield]

Right now, the binaries that come withtkinter-gl as distributed on PyPI work on the following platforms:

macOS: x86-64 and ARM64. I'm sure it works down to 10.14 Mojave, possibly even earlier.

Linux: x86-64 and every distro from the past 5-6 years we've tried (works on Ubuntu 18.04).

Windows: x86-64 (tested on Win 10 and Win 11).

I don't think adding additional architectures would be very difficult, but we haven't previously had any need to do so.

[Harvie]

Can you please add arm32 and arm64 for linux? That is quite common among raspberry pi users. Windows and osx are probably well covered, since users nowadays dont really have any other cpu options besides the listed ones 🙂

[NathanDunfield]

We'll look into this. Even on the Windows side, arm64 is not uncommon these days. Would you be able to test arm32 on Linux?

[culler]

The main question is whether there exists a CI runner for the architecture. I see that github is now offering 64 bit Arm runners with Ubuntu 22.04 and 24.04. I don't see any 32 bit Arm runners. Older is better when it comes to avoiding glibc incompatibilities. I do own a 64 bit Arm SOC (Odroid, not RPi) which is running Ubuntu 20.04, so I guess I could try building a binary package on that little box. I am not hopeful about finding a 32 bit Arm build system for any OS.

[NathanDunfield]

The main question is whether there exists a CI runner for the architecture.

So far, I don't think we have set up the CI for TkGL or tkinter_gl; I believe you just built the binaries locally. In the case of Linux, the manylinux_2014 Docker image was used if I remember correctly.

There are manylinux Docker images for ARM which I can run on my Fedora 41 aarch64 VM.

[NathanDunfield]

In 5174282, I added support for arm64 on Linux, using the CI artifact from the TkGL commit ad5b4fd.

I tested on Fedora 41, but I'm not sure how old a system they will work on. Ubuntu 2022.04 should be fine as that's what it was build on.

[Harvie]

I think i can test this next week. What would be the easiest way to install it on arm debian and run some example?

[NathanDunfield]

What would be the easiest way to install it on arm debian and run some example?

This should work and not clutter up your main Python installation:

git clone https://github.com/3-manifolds/tkinter_gl
cd tkinter_gl
python -m venv test_env
test_env/bin/pip install pyopengl
test_env/bin/pip install .
test_env/bin/python test/gradient.py  # there are three other scripts in test/ to try too.

[Harvie]

test_env/bin/python test/gradient.py

Tested on i.MX8 MM

root@debian-arm64:~/tkinter_gl# cat /etc/debian_version 
12.10
root@debian-arm64:~/tkinter_gl# uname -a
Linux debian-arm64 5.15.71-generic1 #1 SMP PREEMPT Wed Mar 26 16:15:11 UTC 2025 aarch64 GNU/Linux

Other 3 tests do work as well.

However it takes like 6 seconds to initialize (eg. before gradient or clock hand is shown), then it runs okay. Maybe it's caused by the fact i don't have 2D acceleration enabled on this particular device, because the vendor officialy only supports acceleration under wayland, while i run X. And the CPU emulation seems to be CPU hungry. But anyway i think it prooves tkinter_gl works well on arm.

[NathanDunfield]

@Harvie Thanks for taking it for a spin.

[culler]

How long does it take to load the PyOpenGL python module? I wonder if that is the cause of the delay you are seeing.

[Harvie]

I've timed the main

root@debian-arm64:~/tkinter_gl# tail -n 11 test/clock.py 
if __name__ == '__main__':
    print("START: "+str(time.time()));
    root = tkinter.Tk()
    print("ROOT: "+str(time.time()));
    widget = ClockWidget(root)
    print("Using OpenGL", widget.gl_version())
    print("OPGL: "+str(time.time()));
    widget.pack(expand=True, fill='both', padx=50, pady=50)
    print("PACK: "+str(time.time()));
    root.mainloop()

root@debian-arm64:~/tkinter_gl# date +%s; DISPLAY=:0.0 test_env/bin/python test/clock.py 
1748875290
START: 1748875291.079275
ROOT: 1748875291.3171017
Using OpenGL 4.5 (Compatibility Profile) Mesa 22.3.6
OPGL: 1748875291.5545275
PACK: 1748875291.5547512

It takes 1 second before the main is even executed. But the graphics are rendered only couple seconds after the mainloop() is called... But again, that might be different on machine with proper acceleration.

[culler]

Thanks. Loading PyOpenGL happens before main() is executed. So it is
not the reason for the delay you are seeing before rendering starts.