GNOME Bugzilla – Bug 792174
GtkGLArea fails to create complete gl framebuffer on some hardware (Gtk-WARNING **: fb setup not supported)
Last modified: 2018-05-02 19:39:10 UTC
The gtk warning: "Gtk-WARNING **: fb setup not supported" occurs when the gtk_gl_area_draw function is invoked and opengl rendering fails. This only occurs when I run my application on a laptop (lenovo L540 with Intel 4600 graphics), the same code runs with no problems on a number of desktop PCs. I have also tried the example application at https://github.com/ebassi/glarea-example/ and the same problem occurs on the laptop.
I get this on GTK+ 3.22.28 from MSYS2 on Intel HD Graphics 4000: https://bugzilla.gnome.org/show_bug.cgi?id=794283#c5 I have no idea whether it's correct; it seems reasonable to me to report if GTK+ can't do something it's asked to do... is there indication out there that this *should* work?
(In reply to Daniel Boles from comment #1) > I get this on GTK+ 3.22.28 from MSYS2 on Intel HD Graphics 4000: > https://bugzilla.gnome.org/show_bug.cgi?id=794283#c5 > > I have no idea whether it's correct; it seems reasonable to me to report if > GTK+ can't do something it's asked to do... is there indication out there > that this *should* work? When I looked at bit deeper, opengl was reporting a GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT error but I couldn't find an obvious cause. I think it has something to do with the implementation of the Framebuffer object in the intel drivers, and specifically the Framebuffer EXT functions. The symptoms of the problem are definitely hardware dependent. If I force the Framebuffer to use a texture for rendering by setting GtkGLArea::has_alpha to TRUE then I get something rendered to the GtkGLArea but there still seem to be some issues with the depth buffer / rendering order which I can't resolve. I then recompiled Gtk-3.22 but replaced the calls to the Framebuffer extension functions with their core equivalents (glGenFramebuffersEXT becomes glGenFramebuffers etc). The laptop is running OpenGL4.2 and so the framebuffer object is core. Now if I set GtkGLArea::has_alpha to TRUE, there are no problems at all, but if GtkGLArea::has_alpha is FALSE so a RenderBuffer is used, the GtkGLArea is transparent and nothing is rendered. If I use this modified code on a PC with other graphics hardware(Windows, ATI Radeon 5400, OpenGL4.4), both texture and renderbuffer methods still work without issue . So I don't have a solution but I can at least get something to work by replacing calls to the EXT functions in gtkglarea.c with their core equivalents and forcing the Framebuffer to use a texture for rendering instead of a Renderbuffer by setting GtkGLArea::has_alpha to true. By making this change to gtkglarea.c though, I'm guessing I've lost compatibility with older OpenGL versions where the Framebuffer object wasn't core. Another user of the software is having problems on Intel 4000 graphics hardware that are very similar to those described in the linked thread (Bug 794283, crashing when window minimised). We're going to see if this work around helps next week.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/1003.