When using an Alpha8 font texture, GetTexDataAsRGBA32 converts 0x00 to transparent white.
When using a RGBA32 font texture, ImFontAtlasBuildRenderLinesTexData was writing transparent black.
Note that this widen the small gap between polling g.HoveredID and using IsItemHovered() the later does various filtering.
Added IsItemHovered(ImGuiHoveredFlags_NoNavOverride) to disable that specific state redirect/filter.
Side-effect: fix EndGroup() use of combining HoveredId values when gamepad/keyboard nav is active. Unlikely to have user-visible side effect since IsItemHovered() would have filtered out anyway.
Side-effect: fix IsAnyItemHovered() when gamepad/keyboard is active (but this wasn't the primary intent of this change).
Side-effect: fix using SetItemUsingMouseWheel() while hovering an item and gamepad/keyboard is active. (#2891)
This is (kind of) an OpenGL-only function, which should be avoided when SDL2 isn't using OpenGL.
The only alternative that is recommended is SDL_GetRendererOutputSize, which limits this fix to the SDL_Renderer backend. Still, I think it's better than nothing.
I say that SDL_GL_GetDrawableSize is "kind of" OpenGL-only because it does technically work even when SDL2 isn't using OpenGL.
It's just that it becomes a shim to SDL_GetWindowSize, which is not suitable for high-DPI usage because it reflects the size of the window in screen coordinates, not actual pixels, so it really should be avoided when not using OpenGL.
SDL_PIXELFORMAT_RGBA32 is intended for byte arrays where the channels
are specifically in the RGBA order. However, this is not what
GetTexDataAsRGBA32 does: rather, it constructs an array where each
pixel is an unsigned int in ABGR order. On little-endian platforms,
this does indeed result in an RGBA byte order, however, on big-endian
platforms, this results in an ABGR byte order, which does not match
the PIXELFORMAT enum.
What should be used is the SDL_PIXELFORMAT_ABGR8888 enum, which
specifies that the pixels are in native-endian ABGR, which they are.
Builds have failed on Xcode versions that do not yet support `@available` or do not have new APIs (that are unavailable on target OS version) defined at all. Using true build time version checks fixes these issues.
This is bit of a weird edge case adding weight to ImDrawCmd merging, if we could rework the mess in RenderDimmedBackgroundBehindWindow() we may be able to undo some of that.