Really? I disagree.
X11-based toolkits I have used in C++ are message-based
because they are based on X11. Any graphics call basically sends an X11
protocol message to the X11 server. Such sends are quick. They are
basically asynchronous graphics changes.
But that has no bearing on multi-threaded clients. The issue isn't where
the rendering occurs, or how quickly. It's what happens in other threads
in the client whilst events are being processed, and how those other
threads can affect the GUI, and the data displayed by the GUI. The fact
that the X event loop sends a message to another process rather than
doing the rendering itself doesn't really make any difference with regard
to those issues.
The apps event loop causes any
changes to get flushed through. Java graphics calls are not message
based. There is no graphics event loop that you have direct control
over. This means that graphics calls have to be made on the EDT and
other non-graphics stuff that would slow things down has to be shunted
off the EDT.
But in X clients you *have* to control the graphics event loop. It's
yours to manage, and you'd better do it correctly. As I remember it (and
it's over 10 years since I last did any multi-threaded X programming) X
isn't thread-safe in any way whatsoever. Once your program main thread
enters the X event loop your entire program should be controlled by that
thread, and be entirely event driven. If any event handler causes a delay
it will freeze the display just as it will in Swing.
If you start any other threads then those threads shouldn't make X
rendering calls because they are not thread-safe. The best they can do is
push events onto the X event stack, which isn't entirely different from
SwingUtilities.invokeLater. You have to manage all inter-thread
communication and synchronization manually. You get no help from useful
classes such as SwingWorker available in Java.
The basic difference is that X wasn't designed for a multi-threaded
environment whereas Swing was. If you can do everything you want in a
single thread then I presume X will be fine for you. But if you need
multiple threads then you'd better be prepared for some major headaches.
Swing was designed for a multi-threaded environment so you have to take
account of that whether you want threads or not. If you only have a
single thread it's a burden, but if you do need threads then its a
godsend. If you intend to use a multi-threaded client I'd have thought
Swing would be vastly preferable to X.
Gnome-java looks to me like it would give the same benefits
as the toolkits I am used to since I presume it is based on GTK
underneath, probably via JNI.
That sounds like rather a lot of guesswork to me.
