The issue would generally manifest when laying out multiple items on a same line, with varying heights and text baseline offsets. (#2833)
Some specific examples, e.g. a button with regular frame padding followed by another item with a multi-line label and no frame padding, such as: multi-line text, small button, tree node item, etc. The second item was correctly offset to match text baseline, and would interact/display correctly,but it wouldn't push the contents area boundary low enough.
Note: previously the second parameter to ItemSize() was 0.0f was default, now -1.0f to signify "no text baseline offset request". If you have code using ItemSize() with an hardcoded zero you may need to change it. (+1 squashed commits)
Macro is used to ensure that flooring operation is always inlined even in debug builds. __forceinline does not force inlining in /Od builds with MSVC.
(cherry picked from commit bc165df6fd7969605bbc07b8a6d3d28f9109e8f3)
IMPORTANT: Renamed internal CalcTypematicPressedRepeatAmount to CalcTypematicRepeatAmount and reordered the t1, t0 arguments to t0, t1 !!
If you were using a non-default value for io.KeyRepeatRate (previous default was 0.250), you can add +io.KeyRepeatDelay to it to compensate for the fix. The function was triggering on: 0.0 and (delay+rate*N) where (N>=1). Fixed formula responds to (N>=0).
Effectively it made io.KeyRepeatRate behave like it was set to (io.KeyRepeatRate + io.KeyRepeatDelay).
Fixed the code and altered default io.KeyRepeatRate,Delay from 0.250,0.050 to 0.300,0.050 to compensate.
If you never altered io.KeyRepeatRate nor used GetKeyPressedAmount() this won't affect you.
The Bullet and Leaf ImGuiTreeNodeFlags are now taken into account for Framed/CollapsingHeader tree nodes as well. TreeNodeEx() can be used to specify these flags. A choice was made to left-adjust the Framed text when no Bullet/Arrow is rendered, since this was deemed to look better in the Framed context (especially when considering that CollapsingHeader is drawn using NoTreePushOnOpen, so child/sibling Text items etc will often be non-indented).
Issue is fixed by storing last active color picker color and last hue value when active color picker takes rgb as input. Then if current color picker color matches last active color - hue value will be restored. IDs are not used because ColorEdit4() and ColorWidget4() may call each other in hard-to-predict ways and they both push their own IDs on to the stack. We need hue restoration to happen in entire stack of these widgets if topmost widget used hue restoration. Since these widgets operate on exact same color value - color was chosen as a factor deciding which widgets should restore hue.
Note that some elements won't accurately fade down with the same intensity, and the color wheel when enabled will have small overlap glitches with (style.Alpha < 1.0).
