Dear ImGui, and graphics question

Development
1

Hey all,

I thought I’d share an example of using Dear ImGui, a popular C++ graphical user interface (GUI) library, in conjunction with PsychoPy. This could be used for simple, in-experiment GUIs/text entry/debugging utilities/etc.

I’ve had luck with this binding: GitHub - swistakm/pyimgui: Cython-based Python bindings for dear imgui (not totally stable, but probably fine for a one-off), and took a stab at the machinery to have it play well with pyglet windows (derived from the existing cocos2d/glfw examples). That machinery and an example can be found at GitHub - aforren1/pyimgui-demo.

One thing I ran into while playing around with this was that it didn’t always play well with visuals from psychopy (e.g. ShapeStim, RadialStim below).

without
without1920×1080 23.5 KB
radial
radial1920×1080 35.5 KB

I made a fork with minor changes to ShapeStim (BF: OpenGL tweaks to avoid interference between ShapeStim and pyimgui · aforren1/psychopy@1256131 · GitHub) that makes it look more reasonable,

with
with1920×1080 24.4 KB

but didn’t know whether I was mucking up the OpenGL state elsewhere. Any more OpenGL-savvy folks have an idea why they might not cooperate (some residual texture setting)?

2 Likes
2

That is a really interesting project for us to look into!

3

I’d bet the pyimgui people would love you to pull-request with the additional pyglet intergration (well done) and your tweak to psychopy.visual.ShapeStim looks fine too.

Then we could start exploring how to use this inside experiments! :slight_smile:

4

but didn’t know whether I was mucking up the OpenGL state elsewhere. Any more OpenGL-savvy folks have an idea why they might not cooperate (some residual texture setting)?

Check the window.flip() code which usually sets the state for all successive stimuli drawing. As long as you return to the previous state at some point it should be fine.

5

After a win.flip() I’m sure it will all be fine (that resets everything) but @aforren1’s concern about leaving a broken state is valid for other stimuli drawn after the GUI on this frame.

We do need to test some of the stimuli after rendering the GUI box, particularly, a shape, a TextStim and a GratingStim (or ImageStim). These cover the main rendering methods. This will be easy enough to add to the test suite making sure that drawing the GUI before the others generates the same frame as rendering it after the others.

6

Definitely, it’s in the works (though I need to think about how to structure it, given it’s very similar to the cocos2d integration).

I can hang onto my changes for now and do these as part of the same PR. I can also throw in a stimulus (region) vs. GUI + stimulus (just stimulus region) comparison.

7

After a win.flip() I’m sure it will all be fine (that resets everything) but @aforren1’s concern about leaving a broken state is valid for other stimuli drawn after the GUI on this frame.

Yeah when unsure set everything as it would after a flip :slight_smile:

1 Like