A noob's first impressions of Dear ImGui after just having played with editing the demo

[lfnoise]

master bcac02809f46e9bd4ba190f87481f5896dbb45a3

I am an audio programmer, no game programming background at all (please don't #1586 me! :). But I am interested in this for possible use in a real time audio app.

In general, I'm blown away by the flexibility, depth and completeness. awesome.

I've tested nanovg vs Dear ImGui both at 60fps and Dear ImGui seems much lower CPU cost. Can you say why that is? edit: This is probably irrelevant since it was far from an apples to apples test. I do notice that if I drag the opengl3_example window offscreen, the CPU usage goes way up.

In the demo under context menus it says "<- right click here" but nothing happens for me if I control click, which should be the equivalent of right clicking on the Mac?

For redo, is it possible to use the more customary for Mac cmd-shift-Z instead of cmd-Y? This seemed to work:

bool ImGui::InputTextEx(...)
...
        const bool is_Mac_shift_shortcut_keys = io.OptMacOSXBehaviors && io.KeySuper && io.KeyShift && !io.KeyAlt && !io.KeyCtrl;
...
        else if (((is_shortcut_key_only && IsKeyPressedMap(ImGuiKey_Y)) || (is_Mac_shift_shortcut_keys && IsKeyPressedMap(ImGuiKey_Z))) && is_editable && is_undoable) { ... }

A combo box should allow to both select from a menu or type in a value. These seem to only allow you to select from a menu. I was unable to type into them.

The range controls in the demo are just two controls for min and max? I think of a range control as a single slider with a highlighted range between min and max. On some implementations you can drag the range as a whole up and down, moving both min and max at once. If there is not something like this now, I might make one.

Thanks.

[ocornut]

Hello,

I've tested nanovg vs Dear ImGui both at 60fps and Dear ImGui seems much lower CPU cost. Can you say why that is? edit: This is probably irrelevant since it was far from an apples to apples test.

As you pointed they are different libs with very different purpose. NanoVG isn't really an UI lib, but can provide more rendering features and higher quality ones but it tends to be heavier (the shaders are heavier, more draw call, more work on CPU side).

I do notice that if I drag the opengl3_example window offscreen, the CPU usage goes way up.

This is probably an artefact of your OS setup / GPU drivers than imgui. Dragging the application window has no effect on imgui. In the main.cpp file of that example if you change glfwSwapInterval(1) to glfwSwapInterval(0) the application should run non-throttled, it'll burn an entire core but you can evaluate how fast you can get and measure the total time of imgui + your rendering + swapping. For such a simple demo generally the window swapping/os compositing (which may be proportional to the total surface) may take more time than the imgui side of things.

In the demo under context menus it says "<- right click here" but nothing happens for me if I control click, which should be the equivalent of right clicking on the Mac?

It's not supported at the moment, we forward the mouse buttons as is. I am not a Mac user so I don't know much about it, but we could consider that on the application level left button click with Cmd held could be remapped to right button clicks? This should be a trivial change at the application level. Does the Cmd key typically have other mouse-related uses?

For redo, is it possible to use the more customary for Mac cmd-shift-Z instead of cmd-Y? This seemed to work:

That looks right, I should be able to merge that. Does Cmd-Y does anything standard on Mac?

A combo box should allow to both select from a menu or type in a value. These seem to only allow you to select from a menu. I was unable to type into them

Yes this is not part of the default combo. People sometimes build custom widgets out of existing parts but it's not always easy (see #718 for a related discussion). Typing on a combo to filter among its options vs typing any text would be different widgets. If you want to push this discussion forward let's open a topic dedicated to it.

The range controls in the demo are just two controls for min and max? I think of a range control as a single slider with a highlighted range between min and max. On some implementations you can drag the range as a whole up and down, moving both min and max at once. If there is not something like this now, I might make one.

Current implementation was created pretty quickly to leverage existing code. Also see #76. There's also an API flaw with DragFloat2() (see #1441). Some of the issues are: A) the slider code is surprisingly tricky/subtle/long now (compared to what you'd expect) so hastily duplicating it isn't desirable, may need to be refactored instead to enable custom combination, B) the style we use wouldn't work as well as in the picture you pointed out, we have limited guarantee that the text is readable over the various colors we use. C) the interaction for sliders are currently using absolute position which makes the transition to a proper range widgets non-trivial, we probably need to change them to use relative motion for everything. It's an open topic, I would like to refactor the slider but it hasn't been a priority, feel free to dig into it if you like. We can also move this discussion to #72.

For an audio app where you might have precise expectation of how every widget react, you will probably want to rewrite several widgets (also see: #942). It is one of my long term expectation that internals will stabilize and people gets more and more encouraged to do so. Right now it is a little early to encourage people to write lots of custom widgets, but many have been doing it.

[lfnoise]

Thank you for your answers.

I do notice that if I drag the opengl3_example window offscreen, the CPU usage goes way up.

This is probably an artefact of your OS setup / GPU drivers than imgui. Dragging the application window has no effect on imgui.

I don't mean if I am actively dragging. If I position the window so the content is offscreen and leave it there or if I place another window on top of it that completely obscures the content, then the example will go from about 2% CPU to 60% CPU. I will try some more debugging later.

if you change glfwSwapInterval(1) to glfwSwapInterval(0) the application should run non-throttled, it'll burn an entire core

Actually, if I set glfwSwapInterval(0), FPS goes from 60 to 220 but CPU usage only goes up to 4.8%.

[meshula]

That CPU behavior sounds suspiciously like a bad interaction with App Nap. You might try disabling it for your test application (e.g. https://www.cultofmac.com/253064/how-to-turn-app-nap-off-for-specific-apps-on-your-mac-os-x-tips/) and check if the behavior changes.

The swap interval behavior suggests your frame is limited by rendering on the GPU, not the CPU.

[lfnoise]

Turning off app nap via defaults write NSGlobalDomain NSAppSleepDisabled -bool YES didn't help.

[lfnoise]

In the demo under context menus it says "<- right click here" but nothing happens for me if I control click, which should be the equivalent of right clicking on the Mac?

It's not supported at the moment, we forward the mouse buttons as is. I am not a Mac user so I don't know much about it, but we could consider that on the application level left button click with Cmd held could be remapped to right button clicks? This should be a trivial change at the application level. Does the Cmd key typically have other mouse-related uses?

Control-click is right click on Mac. AFAIK Control-click is always right click. (Command-click is usually for toggling selection on individual items or making discontiguous selections).

If it is a trivial change, I was having a hard time to find the right place to make the remapping. I assumed it should happen in ImGui_ImplGlfw_MouseButtonCallback, but there are many places in imgui.cpp that check button state dynamically and if those places are not also mapped, then things might get confused.

[DoctorGester]

I do notice that if I drag the opengl3_example window offscreen, the CPU usage goes way up.

I have and always had the same behavior on mac even in my own imgui-unrelated SDL2 app. Vsync is ignored when an app is offscreen/minimized, which kind of makes some sense.

You can do something like that (obviously the code is trash since it limits itself to 60fps and both SDL_GetTicks() and SDL_Delay() are not accurate but you get the idea).

[doug-moen]

@lfnoise wrote

In the demo under context menus it says "<- right click here" but nothing happens for me if I control click, which should be the equivalent of right clicking on the Mac?

If you are using a desktop macintosh, you will normally have a 2-button mouse attached. If you are using a mac laptop with a touchpad, then 1 finger click is normally mapped to left mouse button, and 2 finger click is normally mapped to right mouse button (but check the Touchpad control panel to see how it is configured).

So it isn't necessary to map ctrl + left click to right click, but I agree that it would be more "user friendly" for Mac users if this mapping was done, since ctrl + left click is how most Mac users access the context menu.

[haldean]

Obviously I don't know if it'll make it into mainline, but I did just push a patch that adds the native MacOS right click behavior. I'm running with this patch over the docking branch right now and it's working well.

[GabZach]

So, should I just download the docking branch if I want the ctrl-click behavior on my Mac?