Should we move to GLFW windowing by default on Raspberry Pi?

Hello all,

I wanted to seek feedback on whether we should move to GLFW as the default windowing sys on Raspberry Pi. Currently we use ofAppEGLWindow, which can be used in native (brcm`) or x11/mesa mode with these instructions.

My recent testing with GLFW on Raspberry Pi using the mesa driver shows that it works really quite well. The version of GLFW via apt on the RPI is still 2.7, and even the last release 3.2.1 does not work very smoothly, but the master branch of GLFW seems to be rendering quite well using the mesa driver.

Is a move away from ofAppEGLWindow to ofAppGLFWWindow` worth pursuing? The main upside is less maintenance as it would track with desktop windowing. We basically get a lot better UI (e.g. hotplug UI support, etc) and it is easier to port work directly from Desktop Linux to Raspberry Pi. The main downside is that older versions of Raspbian wouldn’t be supported by newer versions of openFrameworks.

I’m happy to take on this transition if there is interest.


First of all, thank you very much for this!

I tried the method 1 (brcm) that work like the old releases
openframeworks by creating the context directly on FB.

I wonder if the method 2 (mesa) GLFW can do the same thing,
without needing an X11 server or an entire desktop manager?

on boards (also not raspberry) with mono core.
it can be advantageous not to install any desktop environment or x11 server.

I took advantage of these technologies (orangepi one / raspberrypi zero) with openframeworks
for the creation of interactive billboards, exploit every single resource it was fundamental.

however, i expect to do some tests these days with Method 2!
thanks for the wonderful job!

good day

Please keep me posted if you do any tests with the mesa driver. Your question is the one I haven’t had time to answer yet. I’ll post here if / when I get some free time to test this.

I plan to test the two methods soon, too!

Quick question though - the GLFW windowing, does it need the X environment to run? A lot of Pi projects generally (from my experience) just needs the Pi to boot up and run the app (without even having to go into the X environment) so does the implementation (and boot times) change at all in that kind of situation?

Personally I’m quite happy with the EGL implementation as it is right now because for bigger projects that do need more powerful windowing functions etc I’d not run them on the Pi anyway but get a small computer (Mac mini or something) because the more powerful apps would probably need more CPU/GPU juice than what the Pi can provide anyway.

Got it running with the legacy brcm drivers and can confirm everything seems to work. For some reason had to use sudo to compile openFrameworks for the first time, but that was a minor annoyance and took a second to figure out.

Once I test everything I need to I’ll format my Jessie microSD card and give method 2 a go - but for now I’m happy with the brcm drivers, everything works the way it always had.

1 Like

unfortunately, method 2 (GLFW) looks for a minimum requirement as: (server X11 or MIR or Wayland)

i tried compiling (GLFW 3.2) with: -DENABLE_OPENGL=FALSE
but as you can imagine, this prevents the creation of an opengl context.

however, I understand that development with GLFW makes things easier,
if for reasons of development abandoned EGL i understand the reason!

Ciao Dario

1 Like

Thanks for checking on this @kashim – that conclusion makes sense. I think we just need to do a resources analysis (what kind of processing / memory overhead is required to have X running). I don’t see why we can’t support both ways, but it will help us figure out what is the best “default” way.

1 Like

For what its worth, my two cents say that minimum boot times are important, so I would rather not start X.