imgui_sdl

imgui_sdl copied to clipboard

Only what's 'inside' a ImGUI widget seems to be cleared correctly, if anything is drawn outside the widget, it won't be cleared ever. Seems to only happen with Windows(only tested with Windows 10). Tested on ubuntu19 and it's working just fine. Screenshot: https://imgur.com/a/A6BpAFl

Would you be able to share a minimal program that reproduces the issue? What SDL version are you running on?

If you don't mind using the entire code: https://github.com/IvanNSBS/CPU-Rastesterizer sdl_test.cpp is the main file and is where i try to load ImGUI/ImGUISDL (again, on linux the code works just fine). The tasks.json on .vscode folder that executes the compilation. MinGW version is 8.1.0 x86_64 posix-seh-rt_v6 (had to manually download and install it) and SDL version is 2.0.10, also contained in the repository.

Apparently, i fixed this bug. I'm not 100% sure because i haven't had the proper time to check if everything is working just fine. Nonetheless, the problem seem to have been fixed by removing the line 581 ( CurrentDevice->SetClipRect(clipRect); ) from imgui_sdl.cpp. There is some static_cast going on, to set the clipRect, maybe the compiler i'm using is having issues with it?

My apologies, I don't really have time to debug projects that large that would require me to setup compilers etc... It seems weird that removing that line would mitigate the issue, I doubt any decent compiler would have any issues with a static_cast. One thing you could try is to add CurrentDevice->DisableClip(); after indexBuffer += drawCommand->ElemCount; and see if that works. It already does disable clipping after all draw commands so I doubt that's the actual issue, but who knows.

There's probably something going with the caching of the clip rect, as I need to clear the clipstack when rendering to textures.

Removing CurrentDevice->DisableClip() prevents the renderer from bounding its update to only the rect from wherever the drawCommand is coming from. In other words, the clipRect is being populated by the rect of the window that the user is interacting with; when the user moves that window, only that window (i.e., the rect on the screen that is contained in that window) is being redrawn.

If you want to have the whole window be drawn (i.e., clear the pixels where the window used to be before you moved it), you need to set the clip rect to be the size of the entire window.

Here is some code to help explain:

const Device::ClipRect onlyTheDrawCommandWindow = {
    static_cast<int>(drawCommand->ClipRect.x),
    static_cast<int>(drawCommand->ClipRect.y),
    static_cast<int>(drawCommand->ClipRect.z - drawCommand->ClipRect.x),
    static_cast<int>(drawCommand->ClipRect.w - drawCommand->ClipRect.y)
};

const Device::ClipRect entireWindow = {
    0,0,
    static_cast<int>(io.DisplaySize.x),
    static_cast<int>(io.DisplaySize.y)
};

//CurrentDevice->SetClipRect(onlyTheDrawCommandWindow); // Clear only the drawCommand's rect
CurrentDevice->SetClipRect(entireWindow); // Clear the entire window

I propose setting the clip rect to be the full window size by default, then update the readme to talk about how to change this to the specific rect of what is coming through drawCommand->ClipRect (see #7 )

Just to make this issue more visual, this is the sort of flickery mess that I get on Arch Linux:

(On some runs the background clears to blue without flicking, but it still leaves trails)

All I did was to clone the repositories and to write this CMakeLists.txt

cmake_minimum_required(VERSION 3.15)
project(imgui-sample)

find_package(SDL2)

add_executable(sample
  imgui_sdl/example.cpp
  imgui_sdl/imgui_sdl.cpp
  imgui/imgui.cpp 
  imgui/imgui_draw.cpp
  imgui/imgui_widgets.cpp
  imgui/imgui_demo.cpp
)
target_include_directories(sample PRIVATE imgui/)
target_link_libraries(sample SDL2::SDL2)

---

The issue isn't the clip rectangle itself, but that disabling the clipping doesn't work as documented in the SDL2 docs (I use Arch Linux sdl2 2.0.10-1).

The issue is that passing a nullptr as second argument does not disable clipping. In fact, it doesn't seem to matter what values I pass to SDL for SDL_RenderSetClipRect as long as it's a valid pointer. SDL_RenderClear is supposed to ignore the clipping region (always clears everything). This works if the clear region is a non-nullptr (clears everything). But if I pass a nullptr it won't do the clear at all (clears nothing; but should have cleared everything).

This code in the SDL2 GL renderer looks fishy (and responsible for it) - note that upstream already has a fixed version.

Apparently SDL_RenderClear should never be affect by the clip-rect. If the clip-rect is enabled, that check will actually disable it there. If the clip-rect is already disabled, it won't happen.

This was fixed, but as this change is only 3 months old, there's no stable release yet. If you are running some cutting edge distribution, you might be able to get some SDL from git. I did not try it yet myself, but I assume it will fix it.

So this likely isn't an issue in imgui_sdl, but in SDL2 itself (specifically, before 2.0.11 - which hasn't been released yet). A workaround would be to temporarily set a clipping region before the clear (so SDL is forced to disable GL_SCISSOR).

Are you also using the GL renderer on Windows?

JesseLawson's commit works for me https://github.com/jesselawson/imgui_sdl/commit/c37cb8719b55d2c736c8977c377a42f76da3ad83

So, is this fixed on Win10?

From what I've gathered, this was an issue in SDL2.0.10, and has been fixed in newer SDL versions.

I can reproduce @JayFoxRox bug (looks exactly like his GIF) with SDL 2.0.12 and Imgui 1.76 on Win10 (Visual Studio 2019).

While my post above is rather incoherent, I can still decipher (and confirm) that this should have been fixed in SDL 2.0.11 using OpenGL already (also see linked code). However, I did not test SDL 2.0.11.

I did just test using this:

• Arch Linux sdl2 2.0.12-1 (using the OpenGL renderer backend)
• imgui 417ac68f82912ae4291e8e9b05abf38877a64b83

in combination with:

1. imgui_sdl 4c69d9a5dac35eb7b2550dcbb32e7d0ed323230b (master I used to have issues with)
2. imgui_sdl 0812f5ed05c0eb801fdb8ae71eb0cc75c95a8cff (current master)

Both versions of imgui_sdl work fine with that version of SDL2 (whereas it didn't work fine using the old SDL2). So I firmly believe that the SDL2 upgrade fixed this issue for me (until proven otherwise).

Note that I specifically asked:

Are you also using the GL renderer on Windows?

Because it is very possible that a similar issue exists in other SDL renderer backends (like D3D).

If you are using the OpenGL backend in SDL2, then I'd suggest to review if the change landed in your SDL2 release (which hg / git revision is it?). If you aren't using OpenGL, you should report it as a bug in SDL2 or review the code yourself.

You should also verify if you are really using the SDL2 that you think you are using (and not some outdated system-wide installation).

(This comment was edited in April 2021 to reflect current situation)

This was reported in https://bugzilla.libsdl.org/show_bug.cgi?id=4752. SDL has moved to GitHub issues since then, so it's https://github.com/libsdl-org/SDL/issues/3357 now.

Additionally, the original content of this comment was updated and moved to https://github.com/libsdl-org/SDL/issues/3357#issuecomment-817275140

Thank you for your efforts.

How do you know which backend SDL uses? I just set the SDL_RENDERER_ACCELERATED and use nothing else. Using SDL_RENDERER_SOFTWARE everything works fine (which is my target anyway).

It loads the correct DLLs for SDL2-2.0.12.

Do you also have the effect that folding the demo window properly clears the window?

I will investigate a bit, but my goal is to use Imgui w/o D3D or OpenGL anyway.

How do you know which backend SDL uses?

Information in code is here which gets accessed through this, which is documented here and here.

Do you also have the effect that folding the demo window properly clears the window?

I don't know. But I also use another backend. I suggest to create minimal samples which show these SDL bugs, then report these bugs upstream so they can be fixed as soon as possible (before applications depend on the broken behaviour, thereby hurting the API forever). In general it takes a couple of years for bugs to have landed in operating systems (LTS variants etc.) - so fixing this soon should be a priority, even if it might not affect you personally. I just won't report it because I can't reproduce it.

It works perfect with D3D11, you just need to build SDL from the sources, because the prebuilt libraries does not activate D3D11 by default @JayFoxRox @aggsol