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?

I humbly disagree. The toolkit should be better archictected and should pull in data lazily for giant datasets.

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.

Quote

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 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...

Of course, to take advantage of it, your component has to be non-transparent and repaint only part which are requested by clip region.

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).

Yes, exactly. And IME the vast majority of developers never look at the clip region at all

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.

I'm very happy that classpath exists, even though I'll probably never use it for work. But I might end up using an embedded VM if they write one (and it's fast enough) so I can ship Alien Flux free of license wrinkles.

Classpath doesn't write VMs. They write the libraries for most (all?) of the free VMs out there. If(!) gcj works for Alien Flux, you could compile it to native code and ship it without license problems.

I don't really want to have to use Jet, it's very awkward and just another thing to add to the long list of headaches induced when doing a release. (Well, it was awkward when I bought it, but it has probably improved).

Pfft. Assuming you're talking more than 10 years off, Java as a language will be long gone before then, and we'll all be using something more powerful, more developer-friendly, and much more appropriate to the tasks of the day. I think the best you could hope for is that VM technology is still in there somewhere, and that Sun are still a big player in the language world. ;D

Languages tend to stick around. Look at fortran, IMHO one of the main reasons it's still around is because the huge amount of scientific libraries. Now take a look at java, it's grown so much in the past years, thousands of classes, and and a lot of packages. It seems that a lot of people are moving to .NET for its huge libraries, and it costs a lot to get into, and it's the same with fortran, java is completely free, if you want a cool IDE like .net has, than IBM has created one for free. I'm not trying to start a flame about 'java VS .NET', theres already a thread about that. What I'm saying is that java is something that's easy to get into, along with a huge amount of classes, it will be a while before some company invests as much money and time into a language as sun and IBM has. If some how a company does manage to spend the time and money, it will look like choped liver for a while before it starts looking like java...

As for open sourceing of java, it might help in certain ways, some of which are languages like groovy and jython which run on java, designers of those languages might like to ship their less buggy version of java with their SDK? Are there any problems with doing this?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org