Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3] 4
  ignore  |  Print  
  Open sourcing Java and its effect in games  (Read 14054 times)
0 Members and 1 Guest are viewing this topic.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #60 - Posted 2004-06-11 14:37:56 »

Java Community Process - it's how additions and changes to the JRE and Java in general are decided.
http://www.jcp.org/

Offline TheBohemian

Junior Devvie




Java will rule them all!


« Reply #61 - Posted 2004-06-18 09:59:55 »

hm, interesting:
http://www.linuxjournal.com/article.php?sid=7413

now I understand why Sun is always pointing at Redhat so bad ... Smiley

cya

TheBohemian

---------------------------------------
my favorite OS: http://jnode.sf.net
Java 1.5 -> 1.4 converter: http://retroweaver.sf.net
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #62 - Posted 2004-06-18 10:12:46 »

Quote
hm, interesting:
http://www.linuxjournal.com/article.php?sid=7413

now I understand why Sun is always pointing at Redhat so bad ... Smiley


I love the way it exposes that really annoying bug in eclipse - SWT - by saying there were only two problems with moving to 64-bit:

Quote

One big problem was Eclipse had never been run on a 64-bit platform and it contained some code, specifically the interface between SWT, the graphics toolkit in Eclipse, and its native C libraries, that assumed 32-bit addresses.


which made me chuckle with pleasure - recalling I no longer have to worry about that **** since moving to java Tongue.

(the other big problem was the truly dismal fact that there was no JVM for AMD 64 Sad Sad Sad which simultaneously makes java look pretty stupid).

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #63 - Posted 2004-06-18 11:43:45 »

It's no surprise that SWT was causing most of their problems (slowness, need to maintain JNI bindings w 64 bit pointers).  SWT may be what AWT should have been, but it was never worth doing.  People still seem to think Swing is slow - it once was, in the days of Java 1.2.  Guess what , it got faster!  No need to go re-inventing everything.

Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #64 - Posted 2004-06-18 14:00:12 »

Actually Swing still is the dog it always was. It should compete with native applications and it just... doesn't. Swing apps feel sluggish and unresponsive, paint slowly and still behave ugly when you resize heavyweight windows.

Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is. The only real reason it feels a bit faster now is that you're probably on a 2GHz computer...

Cas Smiley

Offline zingbat

Senior Devvie




Java games rock!


« Reply #65 - Posted 2004-06-18 14:41:43 »

The solution: 3d abstract windowing toolkit based on jogl.  Grin
Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #66 - Posted 2004-06-18 15:06:28 »

LWJGL methinks Wink

Cas Smiley

Offline Bombadil

Senior Devvie





« Reply #67 - Posted 2004-06-18 15:33:12 »

Quote
Actually Swing still is the dog it always was. It should compete with native applications and it just... doesn't. Swing apps feel sluggish and unresponsive, paint slowly and still behave ugly when you resize heavyweight windows.

That's not true. If you read Jeff's Performance Book you'll see why Swing has improved a lot (like Swpalmer points out) and that if you design your GUI app wrongly, your application will be slow no matter how fast or slow Swing is.

I work a lot with JBuilder and JEdit, both full blown Swing applications: they're fast, responsive and look nice! (Especially Borlands L&F theme). Aside the Window's virtual memory swapping with large Java apps they're as well usable as native apps. On a reasonably fast PC you simply don't see any difference.

Quote
Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is.

You can't even use "serious" Windows versions seriously on a 200 MHz computer so why bother talking about them for desktop reasons?
The only real purpose for a 200 MHz is as a Linux (print) server or such. :-)  {Even for MAME it's way too slow...}

Oops, I'm off-topic again! Sorry...
To go back to topic: Bergen (Norway) will go Opensource now, München (Germany; for you English people: Munich) finally does, and several more. Just to name two big ones which decided this route during the last weeks. It's a good thing. Now where's the connection to Java... ;-)


P.S. Where's Jeff btw? He used to write a lot of nice articles here...
Offline rreyelts

Junior Devvie




There is nothing Nu under the sun


« Reply #68 - Posted 2004-06-18 16:14:40 »

Quote
Actually Swing still is the dog it always was.

Cas! Are you one of those miscreants who's still going around spreading these lies?

We're writing the entire UI for our nextgen product in Swing. Swing performs absolutely great, and is, by far, the most flexible and intuitive windowing kit I have ever used in my life. Our UIs are very complex, yet they are very responsive and intuitive. The flexibility of the API allows us to do all sorts of things that make the interface very ease to use and understand. Now, if you've been trying to abuse Swing for gaming purposes, I could see where you might have problems.

Quote
Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is.

"Try running Windows on a VT100 terminal just to see how slow it really is." That statement is just plain silly.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #69 - Posted 2004-06-18 16:50:17 »

Quote

Cas! Are you one of those miscreants who's still going around spreading these lies?


Agreed Wink.

Quote

We're writing the entire UI for our nextgen product in Swing. Swing performs absolutely great, and is, by far, the most flexible and


You were with me right up to this point:

Quote

intuitive windowing kit I have ever used in my life.


...now that's just wishful thinking (or you must be lucky enough not to work with 70% of swing yourself).


Quote
The flexibility of the API allows us to do all sorts of things that make the interface very ease to use and understand.


It's just a pity that *the most important bits* for doing this in swing ... are completely FUBAR by Sun, and no-one at Sun has ever got off their backside and fixed them. I'm thinking of:
- layout managers: not just a joke, but enough to cause you to lose the will to live
- JTable, JTree, JList, JTextArea: none of them work. All of them have incompatible architecture; none of them interoperate in the painfully trivially obvious ways that even a 10 year old child could have guessed they ought to, if anyone at Sun had asked.
- Listeners and Events: many are incompatible in stupid ways; many that should extend each other... don't; the whole thing about needing explicit source because swing's architecture exposes one of the most dangerous things (recursive infinite loops) by it's fundamental design; the fact that many Event's lack basic data that is necessary to handle them properly

OTOH, I entirely agree with you that some parts are excellent, e.g.:
- Actions. (Just a pity Sun hasn't fully implemented them, and has made it so that you have to create dummy classes all over the place because things like Menus each require an Action Sad )
- Buttons (they got these right, at least)

Quote

"Try running Windows on a VT100 terminal just to see how slow it really is." That statement is just plain silly.


Maybe. But, it's a perfectly valid argument that Swing has no excuse NOT to run fast on a 200Mhz machine. Really.

malloc will be first against the wall when the revolution comes...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #70 - Posted 2004-06-18 17:42:53 »

Hey, no lies. I code Swing all day long. It's crap. 10 years ago I was doing GUIs using Powerbuilder. They were faster on the hardware of the day. They also took about 100th the time to code. 1 step forward, 100 backwards. Enough said about it because obviously your GUIs are much faster than mine Smiley

Cas Smiley

Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #71 - Posted 2004-06-18 18:06:29 »

Quote
Actually Swing still is the dog it always was. It should compete with native applications and it just... doesn't. Swing apps feel sluggish and unresponsive, paint slowly and still behave ugly when you resize heavyweight windows.

Try using Swing on a 200MHz computer if you want to remind yourself how slow it really is. The only real reason it feels a bit faster now is that you're probably on a 2GHz computer...

Cas Smiley


Well, yes I am on a fast computer these days, but for lets say 700 MHz and up Swing has been as fast as anything else as far as human perception.

I've been doing a Swing GUI for a couple years now and I have absolutely no complaints about it's speed.  In fact there are areas where it is clearly faster than the native widgets (JSplitter with live resizing works much better in Swing than the equivalent in native windows).

Offline rreyelts

Junior Devvie




There is nothing Nu under the sun


« Reply #72 - Posted 2004-06-18 18:13:21 »

Quote
...now that's just wishful thinking (or you must be lucky enough not to work with 70% of swing yourself).

It's been a little while since I've done "normal" Swing development - the last "Swing" stuff I wrote was a mapping ui that was primarily Java2D sitting in a JPanel. On the other hand, I've probably worked with every Swing control except JSpinner.

Quote
- layout managers: not just a joke, but enough to cause you to lose the will to live

Granted the default layout managers suck - but what other toolkits do you know that come with something great? Swing puts the hooks in there so you can write your own great layout manager (or use someone elses).  We wrote our own app to graphically layout components, based on the most venerable JGoodies layout, and, to put it mildly, it kicks ass. We can create very professional layouts in a matter of minutes. Don't believe me? Download it for free - http://formlayoutmaker.sourceforge.net/

Quote
JTable, JTree, JList, JTextArea: none of them work.

You're going to have to be more specific here. Of course, there are idiosyncrasities - every toolkit has them. On the other hand, I don't know of a single toolkit that allows me the same ease in customizing the rendering, editing, and backend data models for these components.

Quote
Listeners and Events:

The only problem I have had with listeners and events, is that they aren't documented very well. It's sometimes difficult to know when certain events get published.

Quote
Maybe. But, it's a perfectly valid argument that Swing has no excuse NOT to run fast on a 200Mhz machine. Really.

I disagree. I bet you wouldn't see Aqua running fast on a 200Mhz machine - and new MacOS releases generally run faster on older hardware.

Basically, there's no point for the engineers at Sun to waste their time optimizing to that kind of machine. They should be assuming minimally 16M video memory, 1GHZ processors, and 128M RAM. Most companies are not developing Swing apps for 3rd world countries.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #73 - Posted 2004-06-18 18:17:51 »

Having only used Windows MFC and Amiga UI stuff, I too find that Swing is the best UI framework I have ever used. I do find it mostly intuitive and reasonable.  Though there are a few things that aren't super wonderful.

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #74 - Posted 2004-06-18 18:45:43 »

Quote

Granted the default layout managers suck - but what other toolkits do you know that come with something great?
...


I agree that many toolkits have tended to be broken/buggy or look very very ugly and have hard-to-distinguish elements (like the old ones used by a lot of linux/unix apps aimed at being fast-to-draw).

But, as Cas says, there have also been some diamonds. And java arrived as a "modern" language and made great bounds in learning from what went before. I'm still bitter that they didn't *consistently* learn when it came to toolkit design; as I've said before, I feel sorry for those on the swing team who wrote some parts extremely well, who are let down by the others who wrote some parts extremely badly.

Quote

Basically, there's no point for the engineers at Sun to waste their time optimizing to that kind of machine. They should be assuming minimally 16M video memory, 1GHZ processors, and 128M RAM.


I'm not arguing they should optimize for them; I only think they should remove the MS-quality idiot-code that makes them slow on those machines. I struggle to find a reason (today) for a java app to draw slowly on a 200Mhz machine short of broken video drivers, or the use of DirectX 1.0 or something equally deliberate Grin. Window-painting-accelerating hardware wasn't exactly new even on 200Mhz PC's...

Yes, if all you are runing is one swing app on small datasets on your PC then it doesn't matter so long as it's fast.

But when you are running 10 or 20 of them (note: I can only run about 5 max at once before the problems of java's no-shared-memory and swings poor performance slow the machine  down to unusably slow) then it DOES matter. Poor performance is a major barrier to attempting to use only java apps for all desktop work - which is a very powerful lure to those of us who HAVE to work on multiple platforms day-to-day. OK, so I have no need to dump ultra-mainstream apps like OO and mozilla, but all the specialist apps (like project-mgmt software) whose authors can't afford such effort on x-platform ought to be in java - and that places stress on swing.

malloc will be first against the wall when the revolution comes...
Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #75 - Posted 2004-06-18 21:45:35 »

I can write a better damned toolkit than Swing, on my own Sad Why does it take so many of them to get it wrong?

Cas Smiley

Offline rreyelts

Junior Devvie




There is nothing Nu under the sun


« Reply #76 - Posted 2004-06-18 23:35:12 »

Quote
I can write a better damned toolkit than Swing, on my own

I'll believe it when I see it, Cas. People have been writing alternative ui kits for Java for a long time. Nothing competes with Swing.

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline 20thCenturyBoy

Senior Devvie


Medals: 3


So much to learn, so little time.


« Reply #77 - Posted 2004-06-19 11:49:14 »

NetBeans is a Swing app isn't it? That runs fine on my P3 1GHz. In fact, it runs as good as Eclipse on my machine. The one thing that gives it away is the noticeable pause when you click on a menu or tab for the first time. After that it seems to run fine.

I always thought that the SwingSet demo in the JDK was a liability in terms of first impressions - it really is dog slow and the menus and tabs are extremely laggy. I know it is demonstrating tons of stuff but still...

There are a lot of crud Swing apps out there. I downloaded a Swing email client (granted it was linked from Sun's JavaMail page and supposedly it was not meant to be a GUI showcase) but my God, it was butt-ugly. It had buttons with text right up to the edges,  no menu (!), weird drag'n'drop behaviour, non-standard toolbar, and an unchangeable brown colour scheme.  Technically it worked fine, but it was so ugly that I couldn't use it. God help any non-techie who stumbled across it.

My previous "toolkit" was raw Win32,  so Swing is a huge improvement! I especially like the way you can just chuck a component into a JScrollPane to get scrolling. But then maybe I'm easily impressed. I've yet to use any of the heavy hitters like JTree or JTable.

20thCB

"I have never done unit testing and I don’t find it a very useful concept" - Jonathan Blow
Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #78 - Posted 2004-06-19 16:25:14 »

Bits of the API design are nice. But by and large it's slow and unresponsive to the end user. I don't like to see a big white rectangle sit on the screen before a menu draws itself in its stead about 0.5s later. I don't like the whole screen to flicker repainting itself when I drag a window over another one. Etc. Bleh.

Cas Smiley

Offline rreyelts

Junior Devvie




There is nothing Nu under the sun


« Reply #79 - Posted 2004-06-19 21:49:37 »

Quote
I don't like to see a big white rectangle sit on the screen before a menu draws itself in its stead about 0.5s later. I don't like the whole screen to flicker repainting itself when I drag a window over another one.

Umm, Swing doesn't do that. I've got a crappy Intel graphics chipset at work, so it sure doesn't require any kickass video card. Perhaps you're using a poorly written Swing app? Perhaps there are problems with your video driver? Perhaps you're running on a 200Mhz cpu?

God bless,
-Toby Reyelts

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #80 - Posted 2004-06-19 22:36:55 »

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.

Offline princec

« JGO Spiffy Duke »


Medals: 436
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #81 - Posted 2004-06-20 07:12:32 »

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.

<edit>And it ain't poorly written, I've written it so I know it's kosher Cool

Cas Smiley

Offline JasonB

Junior Devvie





« Reply #82 - Posted 2004-06-20 08:58:34 »

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.

Have you tried not blinking so much when you look at the screen...?

Grin
Offline Bombadil

Senior Devvie





« Reply #83 - Posted 2004-06-20 12:18:19 »

Quote
I can write a better damned toolkit than Swing, on my own :(

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

JGO Coder


Medals: 1


http://t-machine.org


« Reply #84 - Posted 2004-06-20 12:45:56 »

Quote

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.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #85 - Posted 2004-06-20 12:52:02 »

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

malloc will be first against the wall when the revolution comes...
Offline zingbat

Senior Devvie




Java games rock!


« Reply #86 - Posted 2004-06-20 13:20:01 »

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

Senior Devvie





« Reply #87 - Posted 2004-06-20 13:58:34 »

Quote


I use JEdit every day, and it's a trivially simplistic application (from a GUI perspective) and as such unrepresentative.

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

Senior Devvie


Medals: 1


Who, me?


« Reply #88 - Posted 2004-06-20 19:08:02 »

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.

Hellomynameis Charlie Dobbie.
Offline rreyelts

Junior Devvie




There is nothing Nu under the sun


« Reply #89 - Posted 2004-06-20 19:27:32 »

Quote
I've sat in front of NetBeans holding mouse buttons down for half a second so that a click is recognised.

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

About me: http://jroller.com/page/rreyelts
Jace - Easier JNI: http://jace.reyelts.com/jace
Retroweaver - Compile on JDK1.5, and deploy on 1.4: http://retroweaver.sf.net.
Pages: 1 2 [3] 4
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Mr.CodeIt (10 views)
2014-12-23 03:34:11

rwatson462 (38 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!