Dear ImGui – Bloat-free graphical user interface library for C++

Post by eska » Wed, Nov 04, 2020, 8:15 PM UTC

JabavuAdams wrote: post #90

flohofwoe wrote: post #89

Earlier quoted context omitted.

There are a lot of hidden traps when rendering anything on modern operating systems that add small latencies and those small latencies add up quickly (it was much easier on old 8- and 16-bit computers). For instance rendering something that "sticks" to the system mouse pointer and doesn't lag a few pixels behind when moving the mouse is surprisingly hard if you're rendering through a 3D API (compared to going through…

I think if it as Casey Muratori's "brain fart" that made sense in his context but that other developers have latched on to because of his influence in indie game circles. I have massive respect for him, and followed everything he did back in the late '90s and early aughts, but he's quite opinionated and has some peculiar code aesthetics / trade-offs.

    I think if it as Casey Muratori's "brain fart" that made sense in his context [...]
    I have massive respect for him, [...]

Post by sitic » Wed, Nov 04, 2020, 8:41 PM UTC

enriquto wrote: post #146

10000truths wrote: post #118

Earlier quoted context omitted.

If you really want to go barebones, just mmap /dev/fb0 and do a memset 0 on the region of screen that you want black. Key/pointer events are a matter of reading files from /dev/input.

Ha! But I want to open a window , if possible portably between linux and windows (just like glut was). It seems to me that we are adding a lot of complexity and going backwards feature-wise.

Post by malkia » Wed, Nov 04, 2020, 8:56 PM UTC

flohofwoe wrote: post #76

ratww wrote: post #75

Earlier quoted context omitted.

> Wouldn't it be possible to separate the public API from the internal implementation so much that the library appears "immediate mode" on the outside, but is completely "retained mode" on the inside? It is possible but you would need some severe API changes... you could either ask the users to use unique names for each widget, or something similar like storing references between frames. Alternatively you'd have to f…

Dear ImGui already uses such "implicit" widget ids, by default it hashes the widget's label string, window title or name, with a convention to add an invisible 'identifier string' to the label string separated by a "##" (e.g. "Label##id") - for the case that the visible label string needs to change or isn't unique within the current scope. There are also separate PushID/PopID functions to manage such widget ids in "m…

Post by eska » Wed, Nov 04, 2020, 9:00 PM UTC

DonHopkins wrote: post #126

varispeed wrote: post #96

This is neat, but the problem I always had in these type of libraries is that they only work enough for the examples to be usable. As soon as I wanted to do something that was not in examples, that would either won't work at all or needed a horrible hack to work. I can't give a real example from the top of my head, but I am thinking like the examples would not show how to do a modal popup window and then you learn wh…

I agree. They work fine for simplistic interfaces with a few buttons, but what about more complex widgets, like plain/rich/code text editors, that have a lot of different callbacks and fire many different asynchronous events? Sure, a button function that returns a boolean can be used as a simple parameter to an if statement, but you would would need a switch statement to test for all the different events that a text…

    // ui.h
    bool has_keyboard_focus(uint64_t widget_id);


    // ui.cpp
    struct UIData {
        uint64_t focused_widget_id;
        int16_t cursor_x, cursor_y;
    } ui_data;

    bool has_keyboard_focus(uint64_t widget_id) { return ui_data.focused_widget_id == widget_id; }

    // my_widget.h
    EditMode my_widget_get_edit_mode(uint64_t widget_id);

    // my_widget.cpp
    map widget_id_to_edit_mode;
    option my_widget_get_edit_mode(uint64_t widget_id) {
        auto itr = widget_id_to_edit_mode.find(widget_id);
        return itr != widget_id_to_edit_mode.end() ? itr->second : std::nullopt;
    }

Post by malkia » Wed, Nov 04, 2020, 9:01 PM UTC

formerly_proven wrote: post #46

exDM69 wrote: post #39

As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constantly…

> As much as I like Dear ImGui, the immediate mode paradigm doesn't work everywhere. The problem of "page tearing" (not to be confused with vsync) means you either need to render frames continuously, or at least 2 frames for every time you get input or need to implement some kind of "retained mode state tracking" on top of Imgui. It's good for games, but for applications where you're not rendering new frames constant…