Examples: add Gtk3/OpenGL3 example

[djdeath]

I've been using different flavors of Gtk3 bindings on Desktop/Linux so that I can have some level of integration with the window manager (i.e client side decoration on Wayland, retina displays, etc...).
I figured somebody might want to reuse that, so here is a PR that reuses the existing OpenGL3 rendering implementation and just sets up the window system through GTK+.

The makefile only supports Linux but I'm pretty sure someone could add support for MacOS/Windows in a few lines (unfortunately I don't have such systems).

[ocornut]

@djdeath Thanks for the PR.
It's a little frustrating that we have to use the KeyMap[] facility like that, but like the OSX binding, it is mostly due to how ImGuiIO is designed.

Some quick comments:

• Your comments still mention GLFW, some mention Cogl and ImTextureID in the gtk3 code (unnecessary)
• It is unnecessary costly to include gtk3.h from the .h file, could the structures be forward defined?
• The header of both .h and .cpp are missing the "implemented features" and "missing features" block to document clipboard support, how are the key mapped (in this case we need a specific explanation as the keys cannot be retrieved with the GDK_key_ enum), and the lack of mouse cursor shape support needs to be added a Missing Feature in the header.
• Mouse position needs to be ImVec2(-FLT_MAX, -FLT_MAX) when missing. (set to -1,-1 if no mouse / on another screen, etc.) seems like it was taken from an old example.
• The coding style of imgui and examples mandate type* name and not type *name, braces on new lines and indenting with 4 spaces. Some of the code submitted doesn't follow those rules.
• The gl3w.h include needs to carry the same comments carried by other examples.

[djdeath]

Thanks @ocornut, updated, hopefully I didn't miss anything.

Your comment about GDK_key_ enum made me realize I could things a bit differently so you can call ImGui::IsKeyPressed(GDK_key_a); for example.

[ice1000]

@ocornut What do you think about this? It works perfectly on my Ubuntu 16.04 machine.

[ice1000]

I mentioned that gtk3 has enabled vsync by default (the Framerate is around 60fps, which is good but uncontrollable. The vsync provided by glfw doesn't work on my machine, making the glfw example becomes about 3000fps and it's extremely CPU-consuming, so I made my own fps locker to control the fps by sleeping the main thread and disabled the default vsync functionality.). Is there a way to disable vsync in your implementation?

[djdeath]

I have to admit, I don't pay too much attention to the vsync.
Most of the applications I write are not really performance/timing sensitive.

Though one thing I really like, is to not have the application drain 100% of the CPU.
The trick that I've used so far is to not redraw unless needed.
If you drop this line from the main.cpp : 5dcc8f9#diff-5da526b88d995bc885990ea8e26ccbf8R73
The GTK+ example should only redraw on events.
That's not good enough for a good experience. Usually I trigger a couple of redraws after each event and I also have another trick of monitoring whether something wants text input so that the cursor can keep blinking (that only necessitate a redraw every half a second or so).

Hopefully that's kind of what you're after.

[ice1000]

Thanks for your help. This implementation is already very efficient afaik, thanks again.

[ice1000]

@djdeath I have a minor suggestion: Omar is working on the viewport branch of imgui which requires additional functionality of native backend. Could you please take a look at that branch? You can refer to imgui_impl_glfw.h and imgui_impl_glfw.cpp.

But as the comment in imgui_impl_glfw.cpp said, it's optional.

[djdeath]

Yeah, I'll give it a try. Not sure all window manager will handle this right though...

[djdeath]

I gave a try to the GLFW example on the viewport under Gnome (wayland) and it doesn't work so well.
The dragged window keeps jumping around.
It might be an issue with wayland (which tends to make it hard to position stuff in absolute coordinates compared to X11).

I've also wrote the backend viewport code for Gtk+. Unfortunately GtkGLArea uses a GL context per widget and that just doesn't work well with the current OpenGL3 implementation that creates shaders and wants to use them with any viewport.

[ice1000]

I gave a try to the GLFW example on the viewport under Gnome (wayland) and it doesn't work so well.
The dragged window keeps jumping around.

Does the SDL one have the same issue?

[djdeath]

It's not as bad, but still pretty jumpy.

[ocornut]

@djdeath
As per your comment here and in #1542

I gave a try to the GLFW example on the viewport under Gnome (wayland) and it doesn't work so well.
The dragged window keeps jumping around.

This part you haven't mentioned in #1542 but if the most important thing I'd hope to get details (gif/video) and support on, if you can help ;) Getting the GLFW back-end to work properly on all OS is paramount to the success of mult-viewport.

I've also wrote the backend viewport code for Gtk+. Unfortunately GtkGLArea uses a GL context per widget and that just doesn't work well with the current OpenGL3 implementation that creates shaders and wants to use them with any viewport.
[...]
So trying to draw in the viewport fails because of unknown objects.
I don't know if you're planning on addressing this or whether that's out of scope.

One problem is that even if imgui_impl_opengl3.cpp handled this, it means that custom textures would be unusable across GL contexts.

For now I would prefer to say it is out of scope.

At this point the choice to make is

• either the GTK+GL back-end handle the GL part itself
• either we make the _opengl3.cpp backend more complex (it's already the worst back-end in term of maintenance cost) and I get to maintain that forever.

Consider this is only to support an hypothetical use case (mr ice1000 is the one who burdened you with a suggestion but it's not like we have any users who came looking for a multi-viewport compliant GTK+GL back-end? Do we?). Considering that, from my point of view I would always prefer the choice with less maintenance.. If there are indeed GTK+GL users who wants multi-viewport (without textures) then it's possibly to easily maintain a copy of imgui_impl_opengl3.cpp that does that.

[ice1000]

@djdeath An update of the Makefile script is needed due to a recent refactoring of imgui code base:

 EXE = example_gtk3_opengl3
 SOURCES = main.cpp
 SOURCES += ../imgui_impl_gtk3.cpp ../imgui_impl_opengl3.cpp
-SOURCES += ../../imgui.cpp ../../imgui_demo.cpp ../../imgui_draw.cpp
+SOURCES += ../../imgui.cpp ../../imgui_demo.cpp ../../imgui_draw.cpp ../../imgui_widgets.cpp
 SOURCES += ../libs/gl3w/GL/gl3w.c
 OBJS = $(addsuffix .o, $(basename $(notdir $(SOURCES))))

[ice1000]

@djdeath Your gl3wInit is returning -1, which is unexpected. I did a little search about it and people said it's because the OpenGL context is not initialized. I'm not sure if it's correct but gl3wInit returning -1 means there's something not working. Could you please take a look into it?

[djdeath]

@djdeath Your gl3wInit is returning -1, which is unexpected. I did a little search about it and people said it's because the OpenGL context is not initialized. I'm not sure if it's correct but gl3wInit returning -1 means there's something not working. Could you please take a look into it?

Updated with Makefile change for imgui_widgets.cpp & gl3wInit fix.

[ocornut]

I'll close this with some comments:

• We cannot maintain a GTK3 backend here in main repo. However I would very much encourage if something like this existed in another repo and would link to it from relevant readme/wiki pages. In the meanwhile we are linking to this PR.
• We updated to an event based IO api since 1.87. (New IO keyboard/mouse/gamepad event API (1.87) recap #4921) The g_MousePressed[] stuff are not needed.
• We extended ImGuiKey and removed the keymap system (also New IO keyboard/mouse/gamepad event API (1.87) recap #4921), so the gdk_key_to_imgui_key[] array can we extended.
• Examples: we got rid of the confusing OpenGL loader stuff so can be made a little simpler.

If your or someone else is using this I reckon it should be pretty easy to update. In the absence of a standalone repo, the update could be posted here for reference.