Raspberry Pi window bigger than 2048 pixels?

Hi all,

I’m trying to get a Raspberry Pi (3, B+) to run an app at 2560x1440 resolution. However, whenever I call ofSetupOpenGL with a dimension larger than 2048, I get an “egl_bad_native_window” error, followed by a lot of “egl swapbuffers failed” errors. (no extra code in ofApp.cpp past the default template)

I’ve tried doing it by calling ofSetupOpenGL at a smaller resolution (e.g. 500 x 500), then using ofSetWindowShape(2560, 1440). This seems to do something, but there are some black bars and positioning oddities: while the app reports its width is 2560 (using ofGetWidth()), things under the hood clearly aren’t happy.

Before ploughing on with weird hacks, thought I’d ask here. What’s the proper way of running a large-resolution app on the Pi? Is it possible, or is 2k some sort of hard limit for the hardware?


Not sure, but I think it needs to be a ofAppEGLWindow, not a openGL window. Check the customEGLWindowSettingsExample in the examples/gles folder.

I would try allocating more memory to the GPU via raspi-config

Thanks all, have tried the above (customEGLWindowSettings and a bunch of gpu_mem options). No luck. Here’s the full error output, if it helps:

setupRPiNativeWindow(): screenRect: 2560x1440
setupRPiNativeWindow(): windowRect: 2560x1440
Setting up EGL Display
EGL Display correctly set 0x1
no current renderer selected
default renderer detected
error creating surface: EGL_BAD_NATIVE_WINDOW
verify that provided EGLNAtiveWindow is valid
display(): eglSwapBuffers failed:
display(): eglSwapBuffers failed:
display(): eglSwapBuffers failed:
display(): eglSwapBuffers failed:

Any other ideas?


Here’s a rather stupid idea, but if you try to set up a standard app (1024x768) and then in ofApp.cpp setup do a ofToggleFullscreen() and see what behaviour you get? (And also report the ofGetHeight() and ofGetWidth() after the full screen toggle to see what dimensions it reports?

It might be a rPi limit though, according to this thread tvservice on the Pi can’t report larger than 1080p displays.

Edit: 1920x1200 seems to be default limit on the Pi. Possible to set up a custom HDMI mode, see the thread linked in the next post.

You might need to look at this as well, first see what tvservice reports in terms of the monitor resolution that it finds.


Hey ayruos,

Thanks for your response! Report from tvservice looks fine:

[HDMI DMT (87) RGB Full 16:9], 2560 x 1440 @ 60Hz progressive

Things look like they’re running at that resolution correctly (i.e. I can see individual clean pixels).

When toggling to fullscreen ofGetWidth/Height reports the correct dimensions, but there’s a tonne of flickering and tearing (see attached picture).

I’ve just tried running two demo applications at 1280 x 1440. The first one opens, the second one fails just as if I’d tried to init with 2560 x 1440.

So, must be a memory thing within the Pi? Strange, I would have thought the gpu_mem config for the Pi would have fixed the issue. Will dig around for a bit, further suggestions are most welcome!

I can see that you’re running the app from the desktop environment - have you tried exiting the desktop environment and running it purely from the CLI environment instead? oF doesn’t use the desktop windowing environment on the Pi and not having that running would free up some of the GPU memory.

Have given it a try, still no cigar.

However, after tweaking settings to gpu_mem=256 I was able to run two 1280x1440 apps next to each other using ofSetWindowPosition. I was only able to do this in the Desktop environment since I could open two command lines (as an side - can you do this somehow from the raw CLI environment?).

So it is possible for the Pi to push out that many pixels, but I haven’t managed it in a single application yet.

I’ve played with memory options a bit more, but even with 512MB to the GPU we still can’t run a single 2560x1440 application.

Yeah it’s possible to run two apps from the raw CLI interface. I usually do it with a bash script like the one linked below

The & is important in the first make command.

Oh cool! Gosh that’s useful. Thanks.

Turns out for my project having an app run across two windows is viable - albeit a pain. Will keep looking for ways to run things in a single app at full res, but may have to settle for displaying via two windows for now.

Thanks everyone for your help!

I tried to do this a while ago, I think it’s down to the gpu on the RPI maxing out framebuffer dimensions at 2048x2048. Check the OpenGL ES limits. GPUMEM doesn’t have an impact, my app is set to 512 or 768MB due to a lot of texture usage, to the point that I have to compile on another RPI and copy the files over as there isn’t enough normal memory for g++!

Nice workaround running two apps, might even be possible to run two windows out of the same app which will be easier if you need a single synchronized image. Done that happily on OS X using GLFW for window management, never tried on RPi though.

Cheers @nebulus_design, good to know it’s not just me!

I ended up running two “seperate” apps from the same app. The second had a reference to the first and would simply translate() by half the screen size before re-calling the primary app’s draw code. So it ended up completely seamless thanks to the RPi’s borderless windows. There were some issues around context (e.g. singletons had to be initialised in both apps), still very workable though.

It does also mean everything was getting drawn twice, but this project was so drawing-light it didn’t make an impact. Could have done some manual culling if it became a problem.

1 Like