0
$\begingroup$

I’m writing a multithreaded renderer. It happens to use wgpu in Rust, but that probably has no bearing on my question except perhaps it will influence my terminology.

Currently, I have two threads, a main thread and a render thread. My window is owned by the main thread but a thread safe reference is given to the render thread. The render thread uses this to create and manage a window surface (handle resizes, presentation mode changes, obtaining swap chain texture per frame). I.e. the render thread owns the surface.

In conversation, someone mentioned that the main thread should also own the surface. If that’s the case, is the main thread responsible for acquiring the swap chain texture and passing that to the render thread?

I suppose my main questions are:

  • is there a definitive, perhaps generalised for all platforms, answer to which thread should own the surface?
  • Does ownership equate to responsibility for acquiring and presenting, or can that be done on another thread?
  • I’ve tried searching for this information; where should I be looking to find this out?

I realise this could be subjective, but I’ve tried to make it objective and as specific questions. Please let me know if it’s too open for opinion and I’ll try to edit it. Thanks.

$\endgroup$
1
  • $\begingroup$ The API can make a difference here. Look into the thread safety of the interface functions, they can tell more about functionality. Under windows the message loop should run on what windows calls the main thread. (I want to say must, but there may be some amount of heroic work that can avoid it) If the main thread is also presenting, or doing any other heavy lifting for the render thread then there are times when user input will either be missed or have a sudden lag/stutter. $\endgroup$
    – pmw1234
    Commented Mar 24 at 22:16

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.