Jump to content
  • Advertisement
Sign in to follow this  
svetpet

Multithreaded User Interface

This topic is 720 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I want to move the whole UI logic + rendering, which is based on flash, on a separate thread, while the game logic will be on the main thread.

Have any of you met this problem and how did you solve it?

Do think it is practical to make any part of the UI multithreaded, or it should be left in the main thread, since there might be a lot of synchronization in some screens between the UI thread and main thread?

Share this post


Link to post
Share on other sites
Advertisement
How complex is your UI? How responsive do you want it to be? Why do you want to implement it on a separate thread?

Share this post


Link to post
Share on other sites

Well, I'm not a flash developer but mostly it's not a great idea to put the UI stuff on a different thread than the main thread. As you already said it might get you in trouble because of the synchronization between the main and the UI thread. 

 

I remember when I was doing some JavaFX stuff, that every UI call needed to be on the main thread otherwise the UI elemets doesn't get called/updated at all. Better put everything else to seperated threads.

Edited by Syrious

Share this post


Link to post
Share on other sites

How complex is your UI? How responsive do you want it to be? Why do you want to implement it on a separate thread?

Well the reason I want to implement it on separate thread is the performance. The UI is complex - it has windows, sliders, pop-ups, etc.

Share this post


Link to post
Share on other sites
Plenty of software, including games, can handle complex UIs on the same thread as other operations.

I think you're chasing a red herring here. Your UI is fundamentally coupled to your rendering logic, as well as your simulation logic. It is not trivial to make this even work on multiple threads.


In my experience multithreading UI is usually about a 30-50% slowdown over keeping your UI in your main thread. It's again extremely hard just to get it to work. The investment is almost certainly not worth it.

Share this post


Link to post
Share on other sites

You just have to render it to a separate plane and if you're not running that low-level then render-to-textures and implement your own double or triple buffering.  

It's worth looking for an extension to get a plane if you try it.

 

 

I'm not sure where the notion of fast-enough UI code is coming from - in my experience it's the slowest thing there is.

In cars we use separate threads for overlays because they are so slow and we have to meet performance targets for rendering gauges.

Edited by Shannon Barber

Share this post


Link to post
Share on other sites

I'm not sure where the notion of fast-enough UI code is coming from - in my experience it's the slowest thing there is.


This. Especially with some popular expensive UI middleware in the industry (you know which one), trying to hit performance targets even with simple UI can be a huge a challenge.

Thankfully, that same middleware has lots of support for offloading various parts of UI updates to other threads, and the remaining bits are trivial to offload if you stop thinking in terms of threads and start thinking in terms of concurrency (e.g., stop trying to share state between threads).

Remember, you don't need to do constant communication between the UI and the game. At most, the game needs to package up any updates to game state that must be reflected in the UI and hand that off as a package to a UI script thread, and the UI script thread has to package up events like "button XYZ clicked" and dispatch those off to the main thread. Two SPSC concurrent queues are a very simple solution there. The UI thread can then update scripts, update layout resulting from scrips or data changes, then run the render to an overlay surface (or just generate a command list to be dispatched to the render thread).

Share this post


Link to post
Share on other sites
UI is not intrinsically performance heavy. In terms of rendering and transformation demands it's minimal compared to a typical 3D game, and most game UIs don't attempt half as much dynamic layout as a web browser does. If your UI library (Scaleform?) is slow then that's unfortunate but it's not intrinsic to the problem.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!