Closed rlewkowicz closed 2 weeks ago
Sounds like you just discovered threads and are now overusing them. What do you mean by "windows thread"? Normally you have a UI thread that handles your platform windows and ImGui rendering, you should not separate those.
Having a capture run on a separate thread is fine, but you need to synchronize your threads properly. In general you should try to avoid allocations at runtime. You could f.e. try a pool of textures, fetch and update one that is currently not in use, queue them up for display. On the UI side you could then check once per frame if there is something new in the queue, in that case get the new texture and return the old one to the pool for the capture thread to reuse. But as you said, not really an ImGui issue.
I am sorry Ryan but we are already more than overwhelmed by legit support requests, we cannot be handling random programming questions. I am sure you will find answers on more general graphics programming groups - welcome to programming. You may use graphics debugger such as RenderDoc to help solving your issues too.
@GamingMinds-DanielC
Sounds like you just discovered threads and are now overusing them. What do you mean by "windows thread"? Normally you have a UI thread that handles your platform windows and ImGui rendering, you should not separate those. Having a capture run on a separate thread is fine, but you need to synchronize your threads properly.
I don't appreciate being seen so clearly 😛 j/k. The winrt frame capture callback cannot be blocked (or should not be) at all costs. Then, I never want the main ui window to be unresponsive in any context. I'm planning on forcing the the windows frame to redraw and invalidate on every paint. I need the image to render well, well dragging the window. So regardless of if imgui gets it's own thread, I still have to be able to call render as much as I'd like. At this time I'm just testing the waters. I left this part out, but I have a robust frame handler that's handling a passive active buffer and managing mutexs. I always need imgui to be able to render the srv as fast as it wants.
@ocornut I feel that. The template said questions are allowed so I figured I'd ask. RenderDoc looks cool, even this highlights my issue. I'm just a guy on the internet. You can try to search this stuff, the gaps in between and what you don't know is the hardest. You just effortlessly gave me a tool that will save me hundreds of hours. None of the problems are ever in the context of like, I've already got this texture and I just want to be able to call render as much as I want till it's gone. It's like "I made this 3d cube and now I need to make a shader for it" ya know? I'll ask on stack. I appreciate all your work here so much.
If anyone knows the answer though... If you wanted to render the same texture twice, do you need a new srv each time?
If anyone knows the answer though... If you wanted to render the same texture twice, do you need a new srv each time?
You can reuse a SRV as many times as you want to as long as you don't destroy it by releasing the last reference.
Version/Branch of Dear ImGui:
Latest
Back-ends:
win32 dx11
Compiler, OS:
Win11 MSVC
Full config/build information:
No response
Details:
TLDR: am I supposed to create a new SRV resource for every render with dx11?
Oh man. What a journey all this texture stuff is. The short of it is, I want to take a frame from winrt windows capture, copy it to another gpu buffer and then render it from there. Subsequent updates will just be a copy sub resource region. I've had some model of this working in various iterations (I've re written this thing so many times). Previously though I just recreated a new texture every time.
This is where I learn of the fun that is the windows thread. If I render the thing right off the capture it's fine. But I want the windows thread to be non blocking so I have that running as it's own thread, imgui render as thread, and capture as a thread.
So there's just a class that handles the pointers and along side the texture I create the srv and serve it on request. Tomorrow I will stare at this computer for another 10-12 hours trying to figure out why my window seems to be rendering an empty texture (there's all sorts of stuff I'm doing that might cause that, and not a null one). But to save me some time on a branch of trouble shooting, I just have to make that srv for the original texture and if I update the underlying texture it's just good?