-
-
Notifications
You must be signed in to change notification settings - Fork 10k
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.
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
Make Dear ImGui support explicit multiple contexts used in parallel #5856
base: master
Are you sure you want to change the base?
Conversation
Thank you for the thoughtful and detailed PR. Automating the last step is definitively the right thing to do and I appreciate this as well. While I imagine it is unlikely I can merge this fully soon, I am willing to put some effort merging the first few commits earlier to facilitate this moving forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some quick comments from skimming through the first commits. Please don't take them too seriously (may be quite wrong on a few things). I'm not sure when I'll be able to make sensible progress on this.
imgui_widgets.cpp
Outdated
@@ -3869,7 +3870,8 @@ static bool InputTextFilterCharacter(unsigned int* p_char, ImGuiInputTextFlags f | |||
// Custom callback filter | |||
if (flags & ImGuiInputTextFlags_CallbackCharFilter) | |||
{ | |||
ImGuiInputTextCallbackData callback_data; | |||
ImGuiContext& g = *GImGui; | |||
ImGuiInputTextCallbackData callback_data(&g); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to be a typo using GImGui here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is a typo, I will fix it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I don't know why it displays GImGui
because on the real diff it correctly shows ctx
.
It is possible you commented the diff of the first commit only, but actually on the diff of the branch there is no problem.
PS: On the first commit GImGui
still exist and is still used everywhere
imgui_internal.h
Outdated
ImRect TitleBarRect() const { return ImRect(Pos, ImVec2(Pos.x + SizeFull.x, Pos.y + TitleBarHeight())); } | ||
float MenuBarHeight() const { ImGuiContext& g = *GImGui; return (Flags & ImGuiWindowFlags_MenuBar) ? DC.MenuBarOffset.y + CalcFontSize() + g.Style.FramePadding.y * 2.0f : 0.0f; } | ||
float MenuBarHeight() const { ImGuiContext& g = *Context; return (Flags & ImGuiWindowFlags_MenuBar) ? DC.MenuBarOffset.y + CalcFontSize() + g.Style.FramePadding.y * 2.0f : 0.0f; } | ||
ImRect MenuBarRect() const { float y1 = Pos.y + TitleBarHeight(); return ImRect(Pos.x, y1, Pos.x + SizeFull.x, y1 + MenuBarHeight()); } | ||
}; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was never happy with those functions being in ImGuiWindow (unusual as per our coding style), so I may do a slight refactor earlier to change that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ocornut
Understood. Let me know if you do it and I will adapt.
imgui_widgets.cpp
Outdated
static int STB_TEXTEDIT_KEYTOTEXT(int key) { return key >= 0x200000 ? 0 : key; } | ||
static ImWchar STB_TEXTEDIT_NEWLINE = '\n'; | ||
static void STB_TEXTEDIT_LAYOUTROW(StbTexteditRow* r, ImGuiInputTextState* obj, int line_start_idx) | ||
static void STB_TEXTEDIT_LAYOUTROW(ImFont* font, float fontSize, StbTexteditRow* r, ImGuiInputTextState* obj, int line_start_idx) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feels like adding ImGuiContext*
inside ImGuiInputTextState
would be better here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ocornut
I agree, it would prevent numerous signature change. I felt I could not take this decision myself because having ImGuiInputTextState
pointing to an ImGuiContext*
feels conceptually wrong regarding my interpretation of ImGuiInputTextState
. But if you are comfortable with that choice, it definitely makes things easier.
Hi @ocornut Thank you for your prompt reply and showing interest in my work.
I did not mention it in the PR description but, despite the effort made to be as few disruptive as possible, I am aware this PR is huge and quite disruptive. Just to understand the change enough to feel you own it and that there won't be unexpected problem in the future, I can imagine it is already lot of work. I see this PR as a proof of concept to show the result of my research, and the beginning of a public discussion about some practical details.
I am glad you are willing to merge the first few commits as a first step. It will simplify future rebase. I will update my work to take into account suggestions and issues you raised, then I will prepare a separated PR with just with the first commits |
b3eef32
to
c2d7308
Compare
@ocornut
I have created a subsidiary PR including those 5 commits: #5859 |
thank you! |
Understood, I will close the other PR |
How will this PR affect the docking branch? (And as a corollary, any reason to keep the docking separate? It is such a great feature.) PS: Your first posts details are great. I would add one aspect to the thread local storage, it is for C++20 coroutines. I've been using them and indeed that causes issue because a task can switch threads. One can always get back to a given thread but with no timing guarantees. |
This PR do very very few reorganization. It does have the potential to generate conflict anywhere, but those conflit are simple to solve, it's just a matter of forwarding the context. Once the code compile, it's unlikely that remain any issue. the docking branch will conflict at the location where the code is different from the main branch in imgui.h and imgui_*.cpp file. If the docking branch do not diverge too much from main it should not be a big issue. |
@Dragnalith You are right. Did you add any demonstration the use of multiple contexts in any of the demo? I am running the glfw/vulkan demo and it does not have any threading. PS: After just fixing two conflicts that kdiff3 didn't fix automatically, it works. The docking is active. If @Dragnalith does not have an actual demo with multiple context, I'll create one and test it with the docking. |
@FunMiles there is no demo for multicontext, the demo code is exactly the same as before in order to prove the PR does not introduce any breaking change. What prove it works with multiple context is the fact the PR remove the GImGui global variable from imgui.cpp, so it's technically impossible for ImGui code to produce any race condition as long as the context given as first argument is different. |
I was wrong for the merge. It's only one commit merge.
|
I do prefer the reference too. I have used pointer to follow the style of some already existing function, changing for reference is an easy find & replace. I don't mind it. I let to decision to the maintainers. |
In ImGui.cpp there are 45 places where static ImVec2 CalcWindowSizeAfterConstraint(ImGuiContext* ctx, ImGuiWindow* window, const ImVec2& size_desired) I do see that indeed you added |
@FunMiles
|
I think it is fine to make all functions take a context parameters, more consistent.
|
It makes merging docking harder. It can also make it possible to send an inconsistent context by mistake. |
Okay, I will not make the change. Let me know if you change your mind. I think for all the code inside imgui.cpp which is not part of the API it does not matter much for now. It could be changed easily later with no impact. |
Actually it makes sense. Let me know the decision, I will modified the PR if necessary. |
I am also concerned about possible (accidental) inconsistent use. Ideally at least the debug build would check for such inconsistencies. Even better if the API does not allow the inconsistency in the first place. This is a great PR, and I can't wait to try it. I would need this to work with the docking branch though. |
I don't think docking after or before does make a huge difference. |
What does prevent the docking branch to merge? |
I am not sure I understand the problem with docking and Dragnalith's answer "Actually it make senses" is ambiguous to me. Every change getting merged in master will be merged in docking, docking is maintained and synchronized about every week and when there a major change we merge immediately. On using reference vs pointer arg:
IMHO the reference/pointer thing is a minor detail we can decide on later and not worth going back and forth now. Here's my suggested strategy:
I'll see if there are early commit I can consider merging soon. |
Clarification about my "It makes sense" answer. I meant: I understand that having an API taking both a |
About the script, it's not yet possible to use it automatically. The script does 99% of the work automatically, but it still requires some manuel touch afterwards for some corner cases. Automating the remaining 1% is not impossible, but have a significant cost compared to just do the manual. I wish to pay for that cost only when we are sure we go for the "automated CI" solution. |
As an experiment I have now merged your second commit (shorter than 1st one), reworked as a5e96ff
Separate topic, about the allocation count discussed in #5856 (comment)
|
…5856) This commit is a preparation toward adding ImGui apis with explicit context and making ImGui applications being able to use multiple context at the same time whatever their concurrency model. -- Prior to this commit ImGuiInputTextState::OnKeyPressed was depending on the global context to know which font and font size to use, and if it should follow MacOSX behaviors or not (c.f ConfigMacOSXBehaviors). Instead of using the global context, this commit store the context as attribute of ImGuiInputTextState. Since this state is forwarded to most of text edit related function, it possible to access font, font size and ConfigMacOSXBehaviors from everywhere. NOTE: I have noticed a bug prior to that commit: if the font or font size change while editing the same widget, the ImGuiInputTextState become invalid and there is no code to handle this invalidation. Fixing this bug is out of scope of current pull request. # Conflicts: # imgui_internal.h
-- This commit is part of the conversion of Dear ImGui toward explicit context API. This commit is supposed to be applied *after* make_explicit_imgui.py has been run. -- foo
This helper makes the assumption only one global context in the application. It is not compatible with a Dear ImGui version where the context is explicit. -- This commit is part of the conversion of Dear ImGui toward explicit context API. This commit is supposed to be applied *after* make_explicit_imgui.py has been run. --
…it context Some corner case need to be converted by hand: - API which already had explicit context overload need to be removed - Function call defined in preprocessor define are not handled by the script - Style init function - API defined in code compiled out because of `#if ... #endif` -- This commit is part of the conversion of Dear ImGui toward explicit context API. This commit is supposed to be applied *after* make_explicit_imgui.py has been run. --
-- This commit is part of the conversion of Dear ImGui toward explicit context API. This commit is supposed to be applied *after* make_explicit_imgui.py has been run. --
-- This commit is part of the conversion of Dear ImGui toward explicit context API. This commit is supposed to be applied *after* make_explicit_imgui.py has been run. --
-- This commit is part of the conversion of Dear ImGui toward explicit context API. This commit is supposed to be applied *after* make_explicit_imgui.py has been run. --
61d0a54
to
6d6b190
Compare
@ocornut Let me know your thoughts. PS: only one thing bothers me, I will likely update |
… *GImGui` for consistency (#5856)
I have rebased the branches |
I've taken PS: I have done similar changes to the docking branch as well. |
Hi,
Thank you for contributing.
If you open a PR in the imgui-explicit repo, I will cherry pick the commit
of your branch.
Does it sound okay for you?
…On Wed, Jan 17, 2024, 05:12 FunMiles ***@***.***> wrote:
I've taken v1.90.1-explicit and added support for glfw3/vulkan. How do I
pass on my changes? I will also work on the docking branch.
—
Reply to this email directly, view it on GitHub
<#5856 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSSFH263NJ4IXHQ2EZSYDYO3NLHAVCNFSM6AAAAAARXMYAX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJUGQ2DENJRGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
It sure does. Though the mechanics of it on github may be a bit tricky because my fork is based on the original repo. But I can handle it. |
If somehow you succeed in creating a PR adding just two commits with can be
fast-forward maybe on top of the existing branch, I will merge it from
github interface.
Ano
…On Thu, Jan 18, 2024, 00:25 FunMiles ***@***.***> wrote:
Hi, Thank you for contributing. If you open a PR in the imgui-explicit
repo, I will cherry pick the commit of your branch. Does it sound okay for
you?
It sure does. Though the mechanics of it on github may be a bit tricky
because my fork is based on the original repo. But I can handle it.
—
Reply to this email directly, view it on GitHub
<#5856 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSSFHYTTSL4CDKSM3PHODYO7UPTAVCNFSM6AAAAAARXMYAX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJWGA2DEMJSGI>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
After successfully doing the explicit context docking branch modifications for glfw/vulkan, I started trying to make a demo of multiple contexts. A new issue derives from this and I just want to mention it here: Vulkan allows to do all the commands from multiple threads, and presumably other 3D libraries must offer similar features. From Vulkan's use point of view, two threads can fully work in parallel and never synchronize. Though on some platforms, Leaving that performance issue aside, the new issue is that the processing of events by glfw happens only on the main thread due to some OSs constraints (e.g. MacOS). I think I one solution is to buffer the events associated with ImGui contexts individually and call the ImGui callbacks with a call similar to glfw3's |
Great. There's one thing incomplete in the docking. I do not know if you had something similar with Windows/DX12: there is an event when new monitors are (dis-)connected. That event is global, but yet the original event handler calls a function that now needs a context. It seems that the event should essentially be dispatched to all existing contexts. I am not sure how to really handle that. I have currently commented that part of the code. Here is the original code: void ImGui_ImplGlfw_MonitorCallback(GLFWmonitor*, int)
{
ImGui_ImplGlfw_Data* bd = ImGui_ImplGlfw_GetBackendData();
bd->WantUpdateMonitors = true;
} One solution would be to have a global variable with a timestamp for when that even happens. Then contexts can check that vs their creation time/last check time instead of the flag in their backend data object. Any other idea? |
See #7186 #7155 #5671.
When answering to #6895 (comment)
My initial idea was that multi-contexts support in eg. GLFW backend would rely on having a global map (ImGuiStorage) in imgui_impl_glfw.cpp, so the monitor callback could simply iterate them, but it was not considering parallel multi-contexts. The global map would also mean some constraints on when it is legal to create/destroy a context (maybe an ok constraints). I don't have much bandwidth to help on this, but moving toward multi-contexts support in standard backend would be nice, and obviously parallel multi-context support obviously nicer. Please consider create dedicated issue # to work on narrower topics as this issue is becoming too unwieldy and has a bunch on its plate already to add backend refactors. I would however need you @FunMiles to clarify precisely what is your intended use case, because I don't want us to move mountains and add too much complexity for too-esoteric use cases. While I can see use for backends supporting multi-contexts, them supporting parallel multi-contexts is another thing and I expect people running parallel multi-context imgui to be a very specific kind of user base (e.g. AAA) who most likely have custom backends in place anyway. (And amusingly, I realized when meeting and discussing with Marc that his utter-motive for this PR is one that I consider absolutely unjustified :P but because I think the change is ultimately desirable I don't mind if his motives don't match mine :) |
My motivation is that modern development does require multi-threading. With it comes also the need for better encapsulation/isolation of entities, components, objects, whatever your favorite term of the day is. I also abhor global variables like many programmers. 😄 You may thus understand my interest in this change. When I do a google search with |
I tried doing a PR to your explicit repo, but, I presume because you have another repo that is a fork of imgui, it will not show in the PR interface on github. If you want to look at what I have done, it is in https://github.com/FunMiles/imgui/tree/docking-explicit I have also successfully reached my multi-threading, multi-context goal, albeit with a more costly method than would be achievable with a lot more changes. I will paire down some of the extra fluff I have in there and then put it in another branch. |
@FunMiles
About the branch:
You can fork my imgui-explicit repo vs push your branch in this repo then
you will be able to open a PR.
About your need for multithreaded multicontext, I could not understand the
fundamental problem you are encountering with glfw?
…On Sun, Jan 21, 2024, 02:00 FunMiles ***@***.***> wrote:
If somehow you succeed in creating a PR adding just two commits with can
be fast-forward maybe on top of the existing branch, I will merge it from
github interface. Ano
I tried doing a PR to your explicit repo, but, I presume because you have
another repo that is a fork of imgui, it will not show in the PR interface
on github. If you want to look at what I have done, it is in
https://github.com/FunMiles/imgui/tree/docking-explicit
I have also successfully reached my multi-threading, multi-context goal,
albeit with a more costly method than would be achievable with a lot more
changes. I will paire down some of the extra fluff I have in there and then
put it in another branch.
—
Reply to this email directly, view it on GitHub
<#5856 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSSFBQWPMPGSGUPXPPXU3YPPZZXAVCNFSM6AAAAAARXMYAX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGE3TKNBTG4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I will do that as soon as I can.
Some glfw functions must only be called from the main UI thread. That is the fundamental issue. |
@FunMiles
I understand serious application require a more complex threading model but
I would to confirm one thing: the glfw example is monothreaded right? So no
special multithreading work is required to port it to explicit context,
right?
Also, my 2 cents. I don't think it should be the responsibility of imgui
backend to be multithreaded. If you have to isolate the your window system
in its own thread likely it's not only for ImGui, likely you have custom
backend needs anyway.
…On Sun, Jan 21, 2024, 02:40 FunMiles ***@***.***> wrote:
@FunMiles <https://github.com/FunMiles> About the branch: You can fork my
imgui-explicit repo vs push your branch in this repo then you will be able
to open a PR.
I will do that as soon as I can.
About your need for multithreaded multicontext, I could not understand the
fundamental problem you are encountering with glfw?
Some glfw functions must only be called from the main UI thread. That is
the fundamental issue.
The NewFrame function as well as the creation and destruction of windows
for the docking make such calls.
On the other hand, doing rendering preparation, whether for the actual app
or from imgui does not need to be done on the main thread and in most cases
where the app rendering takes some time, it should be kept off the main
thread (general best practice for any UI app).
—
Reply to this email directly, view it on GitHub
<#5856 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHSSFBKJYBRNDPPCJHGGETYPP6RJAVCNFSM6AAAAAARXMYAX2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMBSGE4TCNJSHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I have both a regular mono threaded example and a multi-threaded one. Doing the multi-threaded has to be done. Without it I had missed a bug in reuse of some Vulkan variables in the single-threaded. Further it also gives an example on how to properly do it, showing which part have to be sent to the main thread. And yes, it does use standard library includes, because there is no way around it. However it is only in the demo code, so I do not think it is a problem. |
I have made the PR to your repo. The demo is single threaded. I have also a demo in multi-threaded that does not touch the backend, but I have not yet provided it. That demo loses performance because most likely due to the lag introduced by awaking threads. My 2 cents: writing a backend for imgui is not a trivial thing. Providing the tools to be able to quickly add correct multi-threading to the existing backends is not as difficult and would be a good thing for the community in general. There is a difference between making a backend multi-threaded and making it multi-thread safe. It is only the latter I would like to see. I really do not understand the heavy drag on this. |
This is tangential to the task discussed here, but FYI i have released Dear ImGui Multi-Context Compositor, a simple helper to facilitate displaying & interacting with multiple contexts simultaneously (e.g. update vs render domains contexts) (Posting here for visibility for please don't reply here, you can post to imgui_club if you have questions) |
Goal
The goal of this PR is to make Dear ImGui support multiple contexts used at the same time whatever the concurrency model. This PR does that by making Dear ImGui context be explicit by introducing a new set of APIs without breaking the previous APIs.
Problem
The problem is discussed in the issue #586 open 6 years ago.
Problem 1: Running ImGui in parallel
It not possible to run ImGui in parallel without introducting race condition. Indeed, today running ImGui in parallel imply concurrent access to the global context. You can store the global context in thread local storage, this solves simple scenario where parallel code run on distinct threads. But for more complex concurrency model thread local storage is not enough.
Example:
Problem 2: Separation of concern
Today, even when not running ImGui in parallel, two modules statically link in the same program using ImGui cannot be independent. Such modules need to be aware of each other existence, and they need to agree on how they will share the use of ImGui (at least they will need to figure out when to save and restore their context). Dealing with this constraint in large projects adds communication burden, and it can become very tricky when integrating external code using ImGui in a code base already using ImGui.
Solution
Making ImGui context explicit to all calls when necessary. This is actually what is mentioned in imgui.cpp comment around line 1053:
// - Future development aims to make this context pointer explicit to all calls.
Approach
No breaking change
Dear ImGui is too well established in the industry to be allowed to introduce breaking change for each API. Instead, I have prefered a two layer approach. API from
ImGui::
namespace remain with no breaking change but are implemented using a new set of API defined in theImGuiEx::
namespace. TheImGuiEx::
are new APIs. they behave exactly as theirImGui::
equivalent except you need to provide an ImGuiContext pointer as first argument (when necessary).Note: I choose
ImGuiEx
name because Ex is usual to mean "Extended" and in this case it can also mean "Explicit".Minimal difference with master
In order to minimize the complexity of future merge, this PR try to keep the difference with master as minimal as possible.
The code for
ImGuiEx::
is actually the old code ofImGui::
with some rename and insert:namespace ImGui
has been renamednamespace ImGuiEx
GImGui
has been renamedctx
ImGuiContext* ctx
has been inserted at the beginning of signature when necessaryctx
has been inserted as first argument of function call when necessaryThe new code for
ImGui::
has been generated at the end of imgui.h in order not to disturb any current work made in the middle of imgui.h.Automatic conversion from implicit to explicit APIs using libclang parser
Chances are I will have to re-do the refactoring again taking into account some comments and suggestions. Because I do not want to refactor manually again and again, I have written a Python script call
make_explicit_imgui.py
to do it for me. This script is based on libclang. It still needs some manually work, but finding function which need an explicit context parameter and the work of modifying function signature and function call have been automated.This script is available here: https://github.com/Dragnalith/make_explicit_imgui
A two steps transformation
In order for maintainer and reviewer to easily understand the transformation I have applied to Dear ImGui code base, my changes can be split in two steps
Step 1: Preparing the code base
The first five commits are pure refactoring and do not change or introduce any new API. Those commits decouple some classes and function from the global
GImGui
context. It prepares the code base in a way so that the only remaining job is to modify API signature and function call. This job can easily be automated.You can find detail explanation in the commit message of those five commits.
Step 2: Add new API with explicit context
The last commit is mainly the result of
make_explicit_imgui.py
script:GImGui
and insertImGuiContext
where it is requiredImGui::CreateContext
,ImGui::DestroyContext
,ImGui::CreateContext
,ImGui::DestroyContext
have been manually rewritten.Design Details
Function Style vs Method Style
We can imagine two call styles to forward the context to APIs.
Function Style:
Method Style:
This PR chose the the function style because it was less disruptive. Indeed, today APIs are split between imgui.h and imgui_internal.h. To keep this separation, we cannot have one context class with both imgui.h and imgui_internal.h APIs. Dealing with this constraint is a bit more complex than just chosing the function style.
IMGUI_DISABLE_IMPLICIT_API
This PR introduces the IMGUI_DISABLE_IMPLICT_API flag. If defined, all implicit context APIs (i.e the historical APIs) are disabled and the global GImGUI is disabled too.
ImGuiTextFilterEx
andImGuiListClipperEx
ImGuiTextFilter
andImGuiListClipper
were both helper class applying to an implicit context. Now that the context need to be explicit those classes need to take context pointer as constructor or as method parameter.To keep backward compatibility, this PR introduces two new classes:
ImGuiTextFilterEx
andImGuiListClipperEx
which are the explicit version ofImGuiTextFilter
andImGuiListClipper
. Implemenation-wise,ImGuiTextFilter
andImGuiListClipper
have been renamedImGuiTextFilterEx
andImGuiListClipperEx
and slightly modified to handle explicit context.ImGuiTextFilter
andImGuiListClipper
have been recreated by subclassingImGuiTextFilterEx
andImGuiListClipperEx
and forwarding the implicit global context to the parant class.ImGuiInputTextState::OnKeyPressed
It was not obvious but
ImGuiInputTextState::OnKeyPressed
was depending on the global context because it needed to know the font and font size for to update the state. The solve the problem, this PR forward the font and the font size as parameters of OnKeyPressed(...). On the implementation side it makes font and font size be forwarded to most of the imstb_textedit functions.ImGuiOnceUponAFrame
ImGuiOnceUponAFrame
is a helper API which does not really make sense in code using explicit context, so it does not have explicit equivalent. The definition of ImGuiOnceUponAFrame has been moved at the bottom of imgui.h with the newImGui::
declarations.MetricsActiveAllocation
ImGui::MemAlloc
andImGui::MemFree
implementation should not depend on ImGui context, but it does today because it is using the global context to store active allocation metrics. This PR change this by introducing a global atomic integer namedGImAllocatorMetricsActiveAllocations
to implement active allocation metrics. This global is defined next toGImAllocatorAllocFunc
andGImAllocatorUserData
globalsOther
IMGUI_DISABLE_*
flags.