Why are most user interfaces single-threaded?

Question

For example, Java Swing and Android UI use the same threading model, in which a single user interface thread responds to update the entire user interface. What made the designers of the framework choose one flow model over another?

Would a multi-threaded user interface model potentially give you more performance, if only at the expense of more complexity? I understand that the latter is a big deal, because the errors associated with the stream are unpleasant, but I wonder if there are any other advantages to the single-threaded model besides simplicity?

Answer 1

What made frame designers choose one stream model over another?

From the horse's mouth :

AWT was originally shown as a normal multi-threaded Java library. But the Java team looked at the experience with AWT and with the dead ends and races that people faced, we began to realize that we were a promise that we could not keep.

This analysis culminated in one of Swing's design reviews in 1997, when we reviewed the state of the game in AWT, and overall industry experience, and we accepted the Swing team recommendations so that Swing support is very limited to Multithreading.

(Read the whole article, she explains this solution in detail and states that exactly the same problems and a possible transition to a single-threaded model occurred earlier in Xerox PARC - a place where almost everything we consider in CS was invented 30 years ago)

Won't a multi-threaded user interface model potentially give you more performance, though at the expense of more complexity?

Absolutely not, because drawing a GUI and handling user actions (which is all that is needed for the user interface thread) will not be a bottleneck in any normal 2D application.

Answer 2

Would a multi-threaded user interface model potentially give you more performance, if only at the expense of more complexity?

Not in most cases, and that added complexity will do more harm than good in most cases. You should also understand that the user interface infrastructure must deal with the underlying OS model. Of course, he could get around the model and distract her from the programmer, but in this case it just is not worth it.

The number of errors caused by multiple threads updating ad hoc ad hoc would far outweigh what would be a mostly meaningless performance gain (if there were even gains, streaming with corresponding overhead due to blocking and synchronization, in fact you you can just degrade performance a lot more often).

In this case, it is better to use multiple threads explicitly and only when necessary. Most of the time in the user interface, you want everything to be on the same thread, and you won nothing if you use multiple threads. UI interactions are almost never a bottleneck.

Answer 3

No, probably not. At least when you try to run threads on the CPU. A lot of parallel processing in various forms already exists on the GPU. Not so much for the simple operation of the graphical interface, but for 3D imagination (shading, reflection, etc.).

Answer 4

I think everything about preventing a deadlock.

Swing components are not considered thread safe, and they do not have to be due to this Dispatcher Thread event. If the user interface was multithreaded, the entire application would have to rely on each component that behaves in a thread-safe manner, and if it was not, then in unclear situations, deadlocks may occur.

So this is just safer.

Not only that, but the same design was chosen by Windows Forms (& .Net), GTK, Motif and others. I wonder if Java will be forced into this decision by the basic APIs of the OS with which they interact. Of course, SWT is forcibly moving into this situation with Windows Forms.

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

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

Answer 5

This is due to the nature of the user interface application.

You have to read the input (mouse or keyboard), send events, let them process and draw the screen again.

Try this in a multi-threaded process.