Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Merging different forks : Discussion #1

Open
38 tasks done
Daandelange opened this issue Dec 2, 2020 · 6 comments
Open
38 tasks done

Merging different forks : Discussion #1

Daandelange opened this issue Dec 2, 2020 · 6 comments

Comments

@Daandelange
Copy link
Owner

Daandelange commented Dec 2, 2020 •
edited
Loading

Various improvements from various branches. See the jvcleave branch.
Everything should still be backwards-compatible with older versions of ofxImGui.

From existing forks

Note: all above points are almost included in this commit, which I used as a starting point for the merge. It's close to current jvcleave/ofxImGui, with the above changes, keeping whitespaces from jvcleave. Imgui versions are both 1.77_WIP aka the docking release.

New Stuff

  1. Examples :
    • Added example-advanced.
      • Moved oF image loading to it and added combining oF drawing with gui rendering (coordinates example).
      • Add custom theme demo to it.
      • Section about loading imgui plugins.
    • Adds Example-Multi-Context to demonstrate chaining
    • Update example-multiwindow (as a WIP)
    • Add a new fonts example.
    • example-demo : Stripped to demo only.
    • example-simple : a minimal ofxImGui setup.
    • example-imguizmo : example with an ofxImGui plugin.
    • Verify/Update all examples for of0.11.
  2. Readme changes :
    • New developper section
      • How to update imgui ?
      • Other dev info.
    • New usage section.
    • Examples text changed
    • Document autodraw feature
    • Add ImGui description, compared to other GUI libraries
  3. New features
    • New shareMode automatic (or manual) setting. (solves having multiple ofxImGui::Gui instances within the same app. Allows multiple addons to use ofxImGui).
    • Update imgui to use official backends. - 2018/06/08 (1.62) - examples: the imgui_impl_xxx files have been split to separate platform (Win32, Glfw, SDL2, etc.) from renderer (DX11, OpenGL, Vulkan, etc.).
      • ofxImGui was using a wrapper based on an old imgui example. These have been replaced by backends, recommended wrappers that are maintained by ImGui. Using these wrappers will make updating ImGui easier. This was also the main motivation for ofxImGuiSimple.
      • ImGui now asks every API user (your app) to create a context, isolating each process/instance/context from one another. (ImGui::CreateContext())
      • This completely changes the way ofxImGui is implemented. Backends and rendering is now separated from oF; this might impact ofxImGui behaviour. Some details below.
      • Use OFXIMGUI_ENABLE_OF_BINDINGS to revert to legacy implementation.
      • Indirectly fixes input latin characters jvcleave/ofxImGui#102 .
    • Multiwindow alpha. OFXIMGUI_MULTIWINDOW_IMPL See notes below.
    • Enables loading custom fonts, including font-awesome icons.
    • Autodraw respects the original behaviour, rendering when calling gui.end(), but not in shared mode. (Note : this is a slightly breaking change, only affecting the rare projects using autodraw, and which enable the new shared mode, and which draw graphics over the GUI : the gui would switch to be rendered above all graphics)
    • Polish everything, see lists in posts below.

Multi-Window/Viewport/Context notes

There's a lot of confusion around multiple viewports, windows and contexts, and most of this is still work in progress. It's useful to read the ImGui Glossary for precise definitions of various terms.
There's a lot of different ways to setup ImGui, and there are different ways to run oF (platform/window manager/number of windows, etc.) As long as there's 1 single oF window, this is quite obvious, and the new chaining methods make this even more flexible. But multiple oF windows makes it more complex. Should the GUI be available in all windows ? If so, should they make one huge UI across multiple windows, or should they each behave independently ? In terms of writing oF applications, the most common scenario would be to have an renderer output window and one or multiple GUI windows, so then you just run ofxImGui in one of them. But that doesn't cover all scenarios.

Some notes/findings/thoughts on this :

  • Multiple Instances, Contexts, Windows, Viewports. What do we really need ?
    • ImGui contexts seems to act as a sandboxing utility to enable using ImGui from different points, acting as a barrier between both. Ensures a binding with a backend for each imgui instance within the same application. Not directly related to rendering, although each instance need a renderer. Seems to be rather for solving multiple imgui instances within the same application.
    • ImGui viewports refers to the feature that allows popping-out gui windows, and to the windows created for that. Also similar: secondary viewports, virtual viewports.
    • ImGui host viewport (or main viewport) : Platform/system windows that can host other imgui windows. Currently limited to 1, extra oF windows should be bound to this in the future. Multiple host windows. It will also be possible to use ImGui without host viewport (only popup windows).
    • OpenGL shared context : In case of multiple windows, Glfw windows need a special setup allowing imgui to share textures between multiple windows.
  • The current implementation is different from Allow multiple instances of ImGui jvcleave/ofxImGui#53, although it implements a part of it.
    This is no real multi context. With chaining enabled, ofxImGui is setup to seamlessly create one context per window, the first caller setting up the ImGui instance.
  • This is also why imgui windows cannot move from 1 glfw window to another one with this solution (example-multiwindow). A better approach could the future multiple host viewports implementation. See also this issue.
  • Depending on the oF context/setup, making Gui::context a singleton (static) can help hook it up (rare cases). Use a single context (multiple windows) or multicontext (singleton) ?
  • ofxImGui legacy : At this point, ofxImGui is about to be empowered, but I guess a lot of users like its simplicity. So now I'm wondering : is this going too far ? Does it make sense upgrading this addon ? Or should this become a clone ? Should there be 2 variants of this plugin : simple & advanced ? This said, there are already a lot of clones around, but they all seem to solve particular use cases... On the other side, without any specific ImGuiConfigFlags on setup(), ofxImGui remains fairly simple and minimal.

ofxImGui Muti-window support

The current multi-window implementation is a (working) draft because this has to be finished and tested.
In my opinion, it's better to wait for ImGui releasing multi-viewport support in combination with directions from this comment to share GLFW window context.
At the moment, it works with GLFW windows, only when they have the same size. (otherwise there are mouse coordinate problems). Not recommended to use.

Wrapper / Engine / Backend notes

This update changes how the GLFW wrapper is interfaced with oF. BaseEngine and EngineGLFW have less importance. However, the engine wrapper logic is close to oF, so I kept bits of it instead of removing it like other implementations. Also it will facilitate implementing the font features.
These backends also use their own glfw event listeners, so I have commented the ofListeners. As ImGui is getting complex, using the backend way looks the most future-proof, while getting the most out of imgui. I've left most of the previous code, it's probably broken, but it can be enabled with OFXIMGUI_ENABLE_OF_BINDINGS.
This changes ofxImGui behaviour a lot, because previously used functions (programmableDrawData(), createDeviceObjects(), etc.) are now handled by the new imgui backends, without any oF related calls.

To reflect these changes, there's also new methods : BaseEngine::NewFrame/EndFrame so that they better reflect the Imgui API. Also, Gui::render() (internal) is now separated from Gui::draw() so rendering is more flexible (handle autoDraw and chaining...). And BaseEngine::draw() has been renamed to render() and simply renders without looking at the config.

The Gui class orchestrates binding with OF and imgui rendering. Depending the setup() configuration, it calls the correct BaseEngine* calls when needed.

Depreciation note : io.RenderDrawListsFn is depreciated since 1.60 and will be removed in ±2.0

Notes on oF + GLFW

The current ImGui backend is not seamlessly compatible with oF's libGLFW. oF0.11.0 uses a pre-3.3 version, which misses a function used by imGui.

  • Downgrade GLFW to 3.3.0 (ofTheo/glfw, used by oF's download_libs.sh)
# If you don't have apothecary
cd OF/scripts && git clone https://github.com/openframeworks/apothecary.git
# Edit ./apothecary/apothecary/formulas/glfw.sh, change to `VER=3.3-stable GIT_URL=https://github.com/ofTheo/glfw.git`
# Update
./apothecary/apothecary/apothecary -t osx -j 4 update glfw
# Copy ./apothecary/glfw to OF/libs/
./apothecary/apothecary/apothecary -t osx -j 4 copy glfw
  • Alternatively, you can open imgui_impl_glfw.cpp and change 3300 to 3400 on the line defining GLFW_HAS_MONITOR_WORK_AREA to disable the missing feature and more.

Note: GLWF 3.4.0 will bring lots of imgui interface improvements (more mouse cursors, better viewports handling, etc.).

I'll update this 1st post as things advance.
@Daandelange Daandelange mentioned this issue Dec 10, 2020
Closed
@Daandelange
Copy link
Owner Author

Just had some time to continue this.

  • GLWF implementation is getting there. (others remain to be implemented/tested)
  • Font loading is now also supported.
  • The "chaining" option is now removed as an argument, and detected automatically during setup.

@Daandelange
Copy link
Owner Author

Daandelange commented Jan 14, 2021 •
edited
Loading

I've added some more examples, updated others. This is starting to look good. :)

I've been able to test in linux_64, iOS-simulator, and extensively for osx. I'll check Rpi later.
Windows, iOS (real-device) and Vulkan, I'm not able to test.

@Daandelange Daandelange mentioned this issue Jan 16, 2021
Closed
@Daandelange
Copy link
Owner Author

Daandelange commented Feb 10, 2021 •
edited
Loading

Rpi compatibility checked !

Last stuff to do :

@moebiussurfing
Copy link
Collaborator

moebiussurfing commented Feb 22, 2021 via email

@Daandelange
Copy link
Owner Author

Hey, Yes, some project flags need to be set so the addon compiles correctly, I guess the vs extension doesn't parse addons.mk (?). (I cannot see your image)
Good point to clarify/improve/document this.

For now, some flags are set here : in addon_config.mk
The imgui backend flags could probably be checked and defaulted in imconfig.h.
For the Vulkan file exclusion, adding some preprocessor conditions so that it doesn't fail when being included.

@moebiussurfing
Copy link
Collaborator

moebiussurfing commented Feb 22, 2021 via email

@Daandelange Daandelange mentioned this issue Jul 11, 2021
Open
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@Daandelange @moebiussurfing