ImGui SDL3 Renderer Multi viewport broken

[HDAKFD]

Version/Branch of Dear ImGui:

Version Latest, Branch: SDL3 Renderer Multi viewport

Back-ends:

imgui_impl_sdlrenderer3.cpp + imgui_impl_sdl3.cpp

Compiler, OS:

Windows 11 + MSVC 2022

Full config/build information:

SDL3 Renderer multi viewport does not draw the ImGui Window itself, it manages to draw the colored back buffer, but never the imgui window itself. I debugged the draw data everything seemed 1:1 to DX11 example

Also i could change the back buffer color just fine so it actually created everything needed. I created this issue since i didn't have any more ideas what could be wrong since everything seems perfectly fine. I would assume something is still not right in the draw data.

Same issue with SDL2 Renderer on the same branch after adding the same features into it.

Tried with: 1920x1080 resolution 100% Windows OS scale

Demo with "native" sdl renderer so something is not right with render data

[ocornut]

Does it happens with unmodified example apps?

[HDAKFD]

Does it happens with unmodified example apps?

Yes it does, these screenshots are from ImGui Examples without any modifications except for that SDL_RenderFillRect for testing, though does not make difference if that is not there.

I use the latest SDL from https://github.com/libsdl-org/SDL, though i do not believe that SDL is an issue here as the same problem persisted to happen with SDL2

[HDAKFD]

Okay so the issue seems to be Fonts, so we have fonts textures created by the main viewport window and apparently we cannot share textures between renderers, so we have to recreate font textures for each viewport.

Multi viewport seems to work when i disable font textures completely

I guess way of implementing this would be just by creating new font texture once window is created and then "pushing" io.Fonts->SetTexID to require font texture before executing the draw code from different viewports

[HDAKFD]

I did fix this but in very whack way, i can do pull request if you don't mind whacky solutions. I did not edit anything but sdlrenderer3.cpp and sdlrenderer3.h

[ocornut]

Wait, the sdlrenderer backend does NOT support multi-viewports so that’s certainly not an unmodified codebase. It does not because SDLRenderer doesn’t support texture sharing.

It seems you may be referring to a broken branch which I have created in order to help SDL developers to have a test bed for an eventual fix.

see https://github.com/ocornut/imgui/issues/5835#issuecomment-2112480603

[HDAKFD]

Wait, the sdlrenderer backend does NOT support multi-viewports so that’s certainly not an unmodified codebase. It does not because SDLRenderer doesn’t support texture sharing.

It seems you may be referring to a broken branch which I have created in order to help SDL developers to have a test bed for an eventual fix.

see #5835 (comment)

So it is not an option to allow multi viewport by porting textures from another SDL_Renderer to SDL_Renderer, rather wait SDL devs to fix it?

Also the PR does work across multiple renderers on NATIVE sdl renderer 3, not opengl or vulkan, etc since it reloaded the font textures, the only thing that wouldn't be supported would be preloaded images, support for that can be added by just getting the pixel data of each SDL_Texture and recreating it in the new SDL_Renderer. Not the most practical thing to do but possible.

Just proof that it runs fine on multi viewport on SDL3 Renderer with the broken branch with the PR applied into it

[ocornut]

i’ll have to think if it is a viable workaround, the problem is that the cost for it would largely depends on font atlas texture size, potentially too expensive to create an enormous texture for a tooltip. It also won’t work with users texture.

Part of the problem is to decide if it is a better strategy to implement heavy workarounds to cope with SDLRenderer3 limitations, rather than push the devs to improve it. The truth is this is a very limited API, i am not sure i want to encourage anyone to use SDLRenderer presently.

[HDAKFD]

have to think if it is a viable workaround, the problem is that the cost for it would largely depends on font atlas texture size, potentially too expensive to create an enormous texture for a tooltip. It also won’t work with users texture.

Part of the problem is to decide if it is a better strategy to implement heavy workarounds to cope with SDLRenderer3 limitations, rather than push the devs to improve it. The

I would hope SDL allowed the shared textures as it doesn't seem such a big deal from their end, the only reason i ever have interest in SDL is because of emscripten SDL bind with canvas system.

Multi viewport comes as a role breaker with SDL since im working on some kind of imgui support with HTML backend. Key feature would be to render each window with own viewport and window (canvas element) making it possible to use imgui windows with browsers default scroll. Would be useable for phones as canvas elements are locked to 30 fps most of the times.

I'll see what SDL does on the backend that makes it such a hard task to have shared textures, since it is really not practical to load textures multiple times.

[ocornut]

I'll see what SDL does on the backend that makes it such a hard task to have shared textures,

Each renderer creates its own device, so it would require a bit of a refactor. See the link I posed and https://github.com/libsdl-org/SDL/issues/6742#issuecomment-2112526378

I would hope SDL allowed the shared textures as it doesn't seem such a big deal from their end, the only reason i ever have interest in SDL is because of emscripten SDL bind with canvas system.

You can use SDL without SDL Renderer, use OpenGL/WebGL directly.

[HDAKFD]

I'll see what SDL does on the backend that makes it such a hard task to have shared textures,

Each renderer creates its own device, so it would require a bit of a refactor. See the link I posed and libsdl-org/SDL#6742 (comment)

I would hope SDL allowed the shared textures as it doesn't seem such a big deal from their end, the only reason i ever have interest in SDL is because of emscripten SDL bind with canvas system.

You can use SDL without SDL Renderer, use OpenGL/WebGL directly.

Wish it was simple as that, I would love to use WebGL only but I already know that it is going to backfire me as I want it to support everyone even without GPU or WEBGL supported browser, canvas offers nice CPU rendering backend with GPU acceleration if needed, that's why canvas is MUST for me, otherwise I would endup with bunch of users that cannot access the interface.

Decided to try something new and create website without writing a line of static HTML or javascript code, fully on c++ since alternative cross platforms apis such as react or flutter are very bloated and very annoying to use.

[ocornut]

I don't mean to suggest people should spam them, but if you wish to like/comment on SDL github issue https://github.com/libsdl-org/SDL/issues/6742#issuecomment-2112526378 it might weight a little bit.