Why are most UI frameworks single threaded?

Question

For example, Java Swing and Android UI both use a single threaded model where a single UI thread is responsible for updating all the UI. What made the framework designers chose one thread model over the other?

Wouldn't multiple threaded UI model potentially give you more performance albeit at the cost of more complexity? I realize that the latter is a big deal because thread related bugs are nasty but I am wondering if there are any other advantages to single-threaded model other than simplicity?

Anyway

Have you looked into the innards of a GUI framework already? Swing is not exactly simple, despite being single-threaded. That'd be a whole lot of complexity to add for something of negligible benefit since it can be done by the application developer just as well. – Conway

I think performance is a significant historical reason for this. Locking has overhead. Java's original AWT is actually MT-safe (along with a lot of the Java 1.0 stuff) and this had a cost. Also in most UIs drawing the screen with a single thread is usually a best practice anyway (with exceptions of course) – Bourgeoisie

@seand. Drawing to the screen is done with thousands of parallel threads. All modern GUIs now build scene graphs and let the GPU render it with their almost endless shader units (yes a comment to a 10 year answer, but it's still a google first page result for this question, so i comment). – Phalansterian

Answer 1

What made the framework designers chose one thread model over the other?

From the horse's mouth:

AWT was initially exposed as a normal multi-threaded Java library. But as the Java team looked at the experience with AWT and with the deadlocks and races that people had encountered, we began to realize that we were making a promise we couldn't keep.

This analysis culminated in one of the design reviews for Swing in 1997, when we reviewed the state of play in AWT, and the overall industry experience, and we accepted the Swing team's recommendation that Swing should support only very limited multi-threading.

(Read the whole article, it explains the decision in great detail and states that the exact same problems and eventual move to a single-threaded model had even occured earlier at Xerox PARC - the place where almost everything we consider bleeding edge modern in CS was invented 30 years ago)

Wouldn't multiple threaded UI model potentially give you more performance albeit at the cost of more complexity?

Absolutely not, because drawing the GUI and processing user actions (which is everything the UI thread needs to do) is not going to be the bottleneck in any sane 2D application.

Handoff

Internet Archive link to the now-missing "the horse's mouth" blog post: web.archive.org/web/20160402195655/https://community.oracle.com/… – Rhenium

Answer 2

Wouldn't multiple threaded UI model potentially give you more performance albeit at the cost of more complexity?

Not in most cases, and that added complexity would do more harm than good the vast majority of the time. You also have to realize that the UI framework must deal with the underlying OS model as well. Sure, it could work around the model and abstract that away from the programmer, but it's simply not worth it in this case.

The amount of bugs caused by multiple threads updating the UI ad hoc would far outweigh what would be for the most part meaningless performance gains (if there were even gains, threading comes with an associated overhead of its own due to locking and synchronization, you may actually just be making the performance worse a lot of the time).

In this case it's better to use multiple threads explicitly and only when needed. Most of the time in a UI you want everything on one thread and you don't gain much if anything by using multiple threads. UI interactions are almost never a bottleneck.

Legionary

Good answer. Yes theoretically 2 cores could update the GUI twice as fast one, but that completely ignores synchronization of the two threads or locking, which realistically you are going to have to do a number of times. Unless you're clever with your synchronization/locking, you could end up making a multithreaded model perform worse than the same model on a single thread (once you finally get it to work). And then you have all of the added complexity in your framework which would ultimately result in a more difficult to use SDK, thus fewer apps on your platform. – Doubletongue

Answer 3

No, probably not. At least not when you try to run the threads on the CPU. On the GPU there is already a lot of parallel processing in various forms. Not as much for the simple GUI work, but for fancy 3D (shading, reflections etc.)

Breathtaking

Answer 4

I think it's all about deadlock prevention.

Swing's components are not considered thread-safe, and they don't have to be because of this Event Dispatcher Thread. If the UI was multi-threaded, the whole app would have to rely on every component behaving itself in a thread-safe manner, and if any didn't, then deadlocks could arise in obscure situations.

So, it's just safer.

Not only that, but the same design has been chosen by Windows Forms (& .Net), GTK, Motif, and various others. I wonder if Java would have been forced into this decision by the underlying OS APIs which they interact with. Certainly SWT is forced into this situation by Windows Forms.

For more info, "EDT" is a good place to start http://en.wikipedia.org/wiki/Event_dispatching_thread

For .NET, the equivalent of SwingWorker is known as BackgroundWorker.

Quintic

well, this way the whole app relies on every component doing all GUI-relevant work on the EDT and if one doesn't, you get a corrupt GUI. – Handoff

True. I guess it's easier to enforce efficient EDT usage than efficient thread-management. – Quintic

Not that I think Swing makes it that easy to manage. I find it quite confusing to remember when you're on the EDT and when not. I seem to remember Groovy's SwingBuilder makes it easier. No idea about Android. Anyway, +1 for your horses-mouth answer. – Quintic

Answer 5

They are all not single threaded anymore. The modern ones all build a scene graph now and render/compose them in different threads. A Html widget does layout calculations not only in multiple threads but multiple processes.

In general with the widespread use of MVVM pattern it makes no sense for complex models. You can update the Models from any thread. IMHO this was the major reason for it's invention not the data binding argument.

You can debate philosophically if you call this still single threaded just because the mouse/key/touch events arrive all in one thread. Manipulations happen in many places nowadays. And the GPU scene graph is rendered with thousands of parallel shaders how does this apply to the question?

Phalansterian

Answer 6

This is because of the nature of an UI application.

You should read the input (Mouse or Keyboard), dispatch the events, let them process and than draw the screen again.

Try do it on multi-thread process.

Flavone

In .NET you can call Console.Read/Write from whatever Thread you want. And it just works. You have not really explained why a multi-threaded app is not in the "nature of a UI application" – Armbrecht