Err, yeah Cas, what the heck are you talking about?
Actually the flickering screen thing is a bug with DirectX and windows., I think. Pretty much anything that uses DirectX on Windows causes the desktop to repaint for no reason. It happens all the time with stuff other than Swing.
Strange, it does for me. I’ve got a 2GHz laptop at work with a GeForce 4 and the latest drivers and half a gig of RAM running JRE1.5beta2 and it’s still awful. The same, in fact, that it has been since I started using it, except with slightly fewer bugs.
I bet Swing could be improved a lot if it were open sourced and had some dedicated nerds looking over it.
I’m still trying to figure out how I can render an entire screen of complex GUI at 60 frames per second on a computer a quarter of the speed and Swing can’t manage an event-driven effort even a tenth as responsively.
And it ain’t poorly written, I’ve written it so I know it’s kosher 8)
Cas 
[quote]Strange, it does for me. I’ve got a 2GHz laptop at work with a GeForce 4 and the latest drivers and half a gig of RAM running JRE1.5beta2 and it’s still awful.
[/quote]
Have you tried not blinking so much when you look at the screen…?
;D
[quote]I can write a better damned toolkit than Swing, on my own 
[/quote]
You must be the new Johnny English.
(I think his ordered night flight in that large cargo plane has been very funny.)
Well, I’ve programmed several GUIs (Wimp, Borland’s nice VCL (like in Delphi), not so nice ones like Win32 + MFC, Motif, …) but Swing’s surely the best of them.
Of course there’s always room for improvements.
Probably Cas and me live in different universes, though. Not only from a programmer’s POV Swing is OK in the universe I live, it’s also responsive and fast enough for virtually any desktop purposes from a user’s POV, again in the universe I live. In my universe we tend to make the following test: let your new colleague who doesn’t know Java sit in front of your computer and let him use Jedit or/and similar nice Swing apps. Of course without telling him it’s an Java/Swing app. Then, 15 or 30 minutes later, ask him what language/platform the app’s been developed in. 9 out of 10 said to me: some nice native one.
I use JEdit every day, and it’s a trivially simplistic application (from a GUI perspective) and as such unrepresentative. Saying that JEdit is responsive is like saying “look, my toolkit can render Notepad without flickering!”. It’s simply not in the same league as big GUI apps (of which Forte/NB would be a better example).
In the interest of fairness, I expect most people who say “I write lots of Swing apps and they’re all super fast” are writing apps with small GUI’s. I’m not as extreme as Cas at condemning Swing - I find raw rendering performance to be quite good - but OTOH Swing has a major problem when the number of elements in the GUI goes above a certain range.
My experience suggests that there’s an O(N^2) or worse algorithm somewhere (if guessing, I’d hazard it’s when walking the container hierarchy multiple times for repaint, revalidate, mouse and focus listening etc) because once performance starts to go, it really goes :(. The biggest problem seems to be when you have a large number of Components - especially obvious when you start using TabbedPane’s.
IMHO this is not a particular bug in Swing so much as an oversight in the overall design: if you’ve ever worked with huge datasets in swing you’ll have found that it’s very poor (often because Sun’s widgets were designed without much planning for how they might be used), and Sun has added a series of hacks (e.g. look at the special “modes” of JTree/JTable whose only purpose IIRC is to alter the algorithms used so that e.g. ultra large tables are only slow instead of very very very very slow) to ameliorate this. This could be fixed by making “Java 2D version 3” (assuming AWT == 1 and Swing == 2) which has fundamental hooks in the basic component hierarchy etc so that the widget engine can optimize things better, instead of relying on app developers to write clever code - but it wouldn’t be easy.
Personally, I’m just bitter that a lot of swing is still so badly architected as to be unusable if you have any credible option - so that I’m still using and extending my > 20 class toolkit that sits on top of swing and replaces more and more of the J* classes with versions that actually work, and don’t suck, and make sense and whose interfaces were actually designed rather than being hacked together by a series of people who didn’t understand what each other was doing (as is the case with many Swing widgets, if you start comparing the API’s for each :(). It really annoys me that I know eventually I’ll have a complete replacement for JTable - what a waste of my life! - simply because Sun’s one is so very very bad.
And I find it insult to injury that the demand for simple, workable, usable alternatives is so high that the various companies selling JTable and JTree replacements charge in excess of $1000 for one or two classes. Ugh.
PS if, in some alternate universe, the Swing team at Sun ever offerred me a job fixing up their incomprehensible and incompatible J* widget interfaces, I’d probably drop everything just to be able to make peace with all the months of stress and pain that are lurking in my subconscious from those shoddy classes and interfaces.
I reckon, as one person working fulltime, I could probably clean up about half the Swing classes in about 6 months, and make them a true delight to use. If I could work with the swing team, with me mostly doing class-interface design and architecture, I reckon between us we could have an orgasmically good complete API in under a year.
Now, if only Scott would release some of that multi-billion cash pile he’s sitting on to employee a few dozen more java-library developers 8)…
Swing is well designed on paper but have you ever looked at the awt and swing source. The comments are very interesting. The probems i have with swing:
-> the use of their own apis for tree and table models instead of using the classes from java.util
-> most events and event listeners are badly documented and dont behave as expected. All those limitations that force code changing swing to run on the event dispatch thread.
-> the use of swing on top of the awt legacy classes. That peer and toolkit stuff should have been forgetten by now. A different peer object for window, component, frame, peerless lightweight components, and those view classes that are neither components or peers. This is just a nightmare.
-> the way they mix bad code with good code in the sources just scares me to hell
-> bad layout management solution. Shure you can get better layout managers from open source projects but sometime you just have to call revalidate() and repaint() yourself. Its not clear in which situations you have to force a visual component to update itself.
-> changing properties that affect the visual aspect of a component not allways cause an automatic update of the display. It seams that this depends on the will of the guy who did the code for a particular component.
Otherwise swing is a very good api if and its suprising it works so well with all these strangeness.
Well, some articles earlier I quoted JBuilder along with JEdit several times. I wrote that both respond and feel equally fast, despite of their difference in complexity.
So… when a very complex Swing app like JBuilder responds and feels as fast as JEdit on a medium PC, using JEdit for a dummy test is OK.
The net result is the very same: both apps are usable in the same way as native GUIed apps. That’s the point.
I also said there’s always room for improvements. I just don’t agree with the well known massive overstatement a la “Swing is $%&/(, useless, a million times too slow” etc. But then, as said, I live in another universe.
Over and out.
I’m no Swing developer, having only written a small handful of apps using it, so I approach this argument from the user’s perspective:
From the little Swing development I’ve done, and from the apps I’ve used that have GUIs written in Swing, my impression is that the interface is obscure and inconsistent, and the applications tend to be flickery and unresponsive. I’ve scoured the docs for the purpose of some obscure function. I’ve sat in front of NetBeans holding mouse buttons down for half a second so that a click is recognised. I’ve seen this dragging-windows-makes-everything-flash effect. I’ve experienced serious pauses while a new window full of controls is initialised. Whatever the root cause it, the user experience from my point of view has been poor.
However, I’m sure things are improving with every new release, and as people use the API more and more they write better interfaces in it. But there’s always the ubiquitous problem Java has: that the problems of the past haunt it, and no one is doing enough to re-educate people about the present.
[quote]I’ve sat in front of NetBeans holding mouse buttons down for half a second so that a click is recognised.
[/quote]
Netbeans is freaking slow. You’ll get no argument from me. That isn’t the fault of Swing. It’s too bad you can’t test-drive the application we’re building, because it looks and runs beautiful, and (to blah^3) it even uses JTabbedPanes and still runs fast, OMFG!!!
Another word to blah^3 - Loading buttloads of data into a UI is just plain dumb. You can’t expect to load a millions rows into a table or combo box, and see it perform beautifully. You do like us, and write a custom model that pages in data as it needs it - fast and beautiful.
God bless,
-Toby Reyelts
I humbly disagree. The toolkit should be better archictected and should pull in data lazily for giant datasets.
Anyway, I’ve never driven huge datasets through swing like this except to see what happened - I just noticed that Sun had added hacks to make it easier (there was a javaone talk on it at one point too IIRC?).
I have driven large datasets where intelligent clip-mgmt and region-caching on the part of JScrollPane should have been more than enough to make excellent performance. Unfortunately, Swing’s architecture doesn’t really do paint-caching, does it? IT doesn’t prevent it, per se (you can override update methods etc), but it doesn’t support it within the fundamental concepts either. Just wondering aloud at 2am, but … I wonder how much faster swing would seem if it did it’s own caching?
It does. If you use your own model, tookit lazily asks you only about the data which is currently visible on screen. What else could be done ? Caching ? IMHO, it is not possible to do it in universal way, too many heuristics would have to be applied - it is quite easy to bolt your own cache tailored to particular usage on top of your model.
It does I wrote an application which was displaying EEG dataset (almost 1GB of data) in single big component inside JScrollPane (with custom written graph component). Model was directly wired to memmapped file. JScrollPane was doing the caching in best possible way - under windows, if no other window is covering the component, it uses blit to copy data, in other case it uses temporary image buffer. It is possible to set this property to JScrollPane to turn it off completly (if you for example, do your own caching - displaying image or such). When I was moving dataset by umpteen pixels, repaints where instant (<10ms). If I moved the scrollbar like crazy, repaints went down to 100-150ms (after all, it was 40k+ antialiased samples on screen at once, with some filtering applied).
Of course, to take advantage of it, your component has to be non-transparent and repaint only part which are requested by clip region.
Sorry, I should have been clearer. I meant that the Swing architecture makes it incredibly easy for the developer to accidentally prevent paint caching from working :).
If you follow Sun’s own tutorials, it’s unlikely any of your code will work with paint caching (because they do not make you check clip bounds all the time). To me this is like the fact that it is possible to write OO code in C - it’s possible, but it’s not “supported” because the language doesn’t really care either way whether you do or not, and doesn’t help you to do it / enforce it. A similar problem occurs the first time a developer tries to add a simple “print” function: they have to rewrite every single component to do clipbounds handling and implement a scheme to divide up their components into pages, and re-create a fresh clip for each page. The low-level tools are there, but it’s not like M/V/C which is forced upon you in many Swing widgets…
As for the lazy model stuff, IME it doesn’t always work because the models themselves were wrongly designed by Sun and you have to do tonnes of work (especially in trees with that evil horrific TreePath class…) to make things come out reasonably. Again, it’s by no means impossible, but IMHO it’s a lot harder than it should be…
Yes, exactly. And IME the vast majority of developers never look at the clip region at all (for a start, it’s a waste of development time the way Swing is currently architected) until the day their GUI has to handle large data sets or complex redraws (e.g. arbitrarily-many-layered graphs, or dynamic DB-fetched data - anything where overdraw becomes a major concern).
I think JEdit is the third worst editor I’ve ever used. It was beaten into second place by Notepad, and of course had no chance to compete with vi at #1.
Cas
Cas must be bored
How many Swing developers out there create their own components after all ? It is not-so-easy work to do it really correctly - and for most programs, not really needed given available components (Swing or third party).
As for the tree interfaces… been there, done that, it took about 2 pages of code to bolt tree aspect on my data structures, with half of method not implemented, other half being one-line conversions to correct format. Drag&Drop was a lot harder, I ended up copying and modifying most of Swing TransferHandler implementation.
Editor flamewar, hehe… IMHO the Norewegian StrongED for RISC OS Archimedes computers has been the very best editor ever. It’s been mighty and still comfortable and of course one of the fastest ones on earth - being developed in hand coded ARM assembler. On my 200 MHz StrongARM RiscPC it still gives a good run to Ultraedit or JEdit on a 2000 MHz PC… 
Back to topic: Opensourcing Java. Nothing new on this topic I guess.
Yesterday the French government anounced they’re going to move one million state PCs to OpenSource. Negotiation with MandrakeSoft und Mozilla Europe are underway.
The 14 000 city PCs of Munich are going OpenSource, too I mentioned. And so on.
[quote]Back to topic: Opensourcing Java. Nothing new on this topic I guess.
[/quote]
The latest articles imply that Sun won’t opensource Java soon.
people who are interested in open-source/Free java may not rely on Sun’s daily dose of confusion about the topic. the real (real := progress + coding) stuff goes on at the classpath project*:
http://www.gnu.org/software/classpath/classpath.html
it has a blog area called planet classpath:
http://classpath.wildebeest.org/planet/
(with the article that caused the latest thread hijacking here …!)
btw:
people disliking open-source/Free software projects sometimes have doubts in the project programmer’s skills - anyone had a look at classpath’s team? IBM & redhat among others - interesting combination
*and the various free JVM projects of course
just found a small presentation about classpath and its future:
http://www.klomp.org/mark/classpath/RH/GNUClasspathRH.html
(may 2004)