Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (481)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (548)
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]
  ignore  |  Print  
  Swing faster than AWT?? ZHUH?  (Read 7909 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #30 - Posted 2003-01-10 08:35:41 »

Aha, my trolling friend, it seems Leknor has explained for you why this should be the case more clearly. It is an ambiguous behaviour and it's certainly undocumented and ought to be fixed as you can break a VM irrevocably in this way.

Cas Smiley

Offline sma

Junior Member





« Reply #31 - Posted 2003-01-10 08:40:00 »

Quote
If you want pure performance and no frills, use pure LWJGL.


Will LWJGL open and manage its own windows? Can I set caption text, min/max/buttons, what's about (modal) dialogs? Browsing over the doc (only a few seconds I admit) I didn't find this functionallity.

Quote

If you want to mix a Java GUI with high-performance OpenGL, use GL4Java and AWT or Swing.


Cas, why do you think that SWT wouldn't be an option to be mixed with LWGL.   I thought, that your library would be kind-of a replacement for GL4Java, some way to get accelerated graphics for Java.  Having some "traditional" GUI framework might help to speed up development.

Or let me ask a different question: Let's say I'd like to create something like the original Warcraft or Battle Isle (both not requiring fancy 3D graphics) game. What would be the best approach in Java.  Let's further say, Windows is the most important platform and Linux would be a nice to have.

Quote

If you want to write productivity applications then SWT will probably work just as well as AWT.


Definitely better than AWT. Not so sure about Swing though. Here it depends on your requirements which one has more advantages.

Stefan

.: Truth Until Paradox!
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #32 - Posted 2003-01-10 08:55:51 »

LWJGL is a replacement for the entire windowing feature of an OS. It turns your PC into a "console", with a screen, speakers, and some input devices, and that's just about all. As such it doesn't integrate with any notion of a windowing system, so SWT and AWT are redundant. You have to write your own - I have, it took about a month to make it perfect. Various others have experimented with writing realtime rendered GUIs too, all with great success. It's a lot easier than it looks.

If you're creating Warcraft in Java then I suspect that a system with enough poke to run Java will probably also be modern enough to have an OpenGL compatible card so I'd go for LWJGL myself Smiley But these days the AWT with its new VolatileImage is producing simple graphics at full speed, if a little buggily. I prefer GL because it lets me scale, rotate, and blend sprites with no noticeable performance degradation.

Although I am wondering whether we need a special 2D interface into LWJGL because there's some plenty fast cards out there that basically have broken OpenGL drivers and don't work as advertised, or for a lot of laptops there is no GL but there's speedy 2D, and that's quite annoying for 2D only stuff.

I'm going to open a thread on 2D in LWJGL.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #33 - Posted 2003-01-10 10:45:15 »

Aha, my trolling friend...

Lol, you invoked the "troll-net", because I demonstrated the relevant problem with threads that you just don't seem to get. That's amusing. I know you hate to admit you're wrong to KevDog, but isn't this pushing it?

it seems Leknor has explained for you why this should be the case more clearly.

Leknor didn't demonstrate anything beyond which I already said.

It is an ambiguous behaviour and it's certainly undocumented and ought to be fixed as you can break a VM irrevocably in this way.

It's a bug in the VM, you yahoo. If you would take the 30 seconds, you could find it in the bug database. As to how you can "break" a VM with this bug, I don't know. You can certainly leak memory to your heart's content - which is the point KevDog was trying to make.

All of this doesn't address the fact, that it is entirely superfluous and wrong-headed to subclass Thread to implement the Runnable interface for SwingUtilities.invoke*. If you can't see that, there is little hope for you.

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 cknoll

Junior Member




Flame On!


« Reply #34 - Posted 2003-01-10 12:58:43 »

rreyelts, will you learn to stfu and READ a post for once?  Did you notice in my post I said:

Quote

Runnable just says your class must implement a method named run().  Threads have nothing to do with it.  invokeLater() is just using the appropriate interface for clients to implement if they want some action performed later.


And then you go on to say in response:

Quote

SwingUtilities.invokeLater() only asks for a Runnable, because it's not going to create a new thread - it's just going to execute the Runnable on the event thread.


We are saying the same thing with respect to invokeLater(), which is you only need to pass it a referenence to a Runnable object wich should be garbage collected afterwards.  Threads have been shown to hang around in the VM without starting them, Whoopiee!  Give that man a medal.

The only explanation for this behavior i can determine is that start() will perform some cleanup after the run() method returns.  I imagine other peer-dependent objects that are created but not used (sockets? windows?) will also exhibit this behavior because they need an explicit call to a cleanup methods (such as dispose() or something) to have the peer released.   Moral of the story here is don't create threads you don't use.

I think the implementation of thread is flawed, it shouldn't create any peer-level objects (os threads) until start() is called (less chance of objects being orphaned).  but, i guess it makes thread pooling faster if peer-level objects are created at instantiation time instead of at start time.

-Chris
Offline rreyelts

Junior Member




There is nothing Nu under the sun


« Reply #35 - Posted 2003-01-10 15:13:44 »

will you learn to stfu

Profanity - wonderful.

and READ a post for once?

Here's some quoting to satisfy you Chris. (I thought I already did that enough, but apparently not for your tastes).

Cas: Er, Kevdog, Thread is a Runnable - I suggest you go and find out what the bug is in your code and change your advice!

Herkules: Yes, but a Runnable is not a Thread. And a Runnable is sufficient. So kevdogs advice is deeply true

KevDog:  Yep, a Thread is a Runnable, but a Runnable is not a Thread   Thread has a lot more overhead.

So, what we see here is Cas telling KevDog that he's written buggy code. KevDog explains that his code is not buggy and he and Herkules both make the point that Thread has more overhead than Runnable - it should therefore not be used in preference to directly implementing Runnable.

I think everybody gets the point, so I'm done.

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 princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #36 - Posted 2003-01-10 15:21:32 »

It's buggy code all right but it's not Kev's fault, it turns out... I should go back and edit my message but then it breaks your quote Smiley No worries now, calm down etc.

Cas Smiley

Offline Kevdog

Junior Member





« Reply #37 - Posted 2003-01-10 17:05:32 »

Wow, don't get too worked up Cheesy
Guess we're all passionate about Java Smiley

My main point was don't use Thread or a subclass of Thread for the invoke functions.

Threads become active when they are created (with new) and not when they are started (you can run Thread.activeCount() after creating a new one).  Active threads are not garbage collected, so if you never run start() they will never be garbage collected.  Whether this is a bug in the JVM or not, I don't know (and don't want to read the JVM spec to find out Cheesy ) but that's the way it currently is.

When I first encountered this, I thought it was a JVM bug in JDK 1.1.8 (we're a bit behind the times!).  I tried a sample on JDK 1.4.0 and it still had the same behaviour, so I assumed it wasn't a bug and was just the way it works.

I changed all the Thread subclasses to Runnable subclasses and all the thread leaks went away.  We no longer have 10,000-50,000 threads hanging around in memory unrun.

There are only 10 types of people, those who understand binary and those who don't!
Offline vanc

Junior Newbie




Java games rock!


« Reply #38 - Posted 2003-01-15 21:19:29 »

You guys should read Thread.java distributed with any JDK from SUN. It clearly shows that after creation, a thread will be added to a ThreadGroup. Only after start() is called, the private exit() will be called from native part. exit() removes the thread from the ThreadGroup which makes the thread garbage collectable.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #39 - Posted 2003-01-15 22:37:45 »

Construction of a Thread() with no parameters, it says in the JDK docs, is the same as passing null as the threadgroup, so it shouldn't be referenced by any ThreadGroup. It's a hole that needs patching all right.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline vanc

Junior Newbie




Java games rock!


« Reply #40 - Posted 2003-01-15 23:17:40 »

If the ThreadGroup passed to Thread construction is null, the group of currentThread() will be used. Anyway, you can __not__ create a thread which no group associates with. That's the current implementation from SUN.
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #41 - Posted 2003-01-16 09:49:15 »

All well and good, but it's not explicitly mentioned either in the JDK docs or in the JVM specification, and that's the problem - it's not a declared behaviour so it leads to unexpected results.

Cas Smiley

Offline markuskidd

Junior Member


Medals: 1



« Reply #42 - Posted 2003-01-16 11:46:37 »

well...

http://java.sun.com/j2se/1.4.1/docs/api/java/lang/Thread.html#Thread(java.lang.Runnable)

Quote

1  
public Thread(Runnable target)

Allocates a new Thread object. This constructor has the same effect as Thread(null, target, gname), where gname is a newly generated name. Automatically generated names are of the form "Thread-"+n, where n is an integer.


Quote

1  
2  
3  
public Thread(ThreadGroup group,
              Runnable target,
              String name)

Allocates a new Thread object so that it has target as its run object, has the specified name as its name, and belongs to the thread group referred to by group.
If group is null and there is a security manager, the group is determined by the security manager's getThreadGroup method. If group is null and there is not a security manager, or the security manager's getThreadGroup method returns null, the group is set to be the same ThreadGroup as the thread that is creating the new thread.

If there is a security manager, its checkAccess method is called with the ThreadGroup as its argument. This may result in a SecurityException.

If the target argument is not null
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #43 - Posted 2003-01-16 13:45:59 »

Yeah, I can read Roll Eyes, but where does it say that a default threadgroup is created by the JVM on startup and the main thread is assigned to it? Not in the JVM specs it doesn't. It still looks ambiguously defined; it's hinted at here and there but never explicit. And as we've noted, the side effects are quite serious, leading to a VM crash or OS resource starvation.

Cas Smiley

Offline Themroc

Junior Member





« Reply #44 - Posted 2003-01-16 15:57:07 »

Well, API-docs never tell you everything, but in my experience I have seen worse API-docs than the one of the JDK. If you just look a little further you can find it in the Java-Tutorial:

http://java.sun.com/docs/books/tutorial/essential/threads/group.html

Every Java thread is a member of a thread group. Thread groups provide a mechanism for collecting multiple threads into a single object and manipulating those threads all at once, rather than individually. For example, you can start or suspend all the threads within a group with a single method call. Java thread groups are implemented by the ThreadGroup(in the API reference documentation) class in the java.lang package.

The runtime system puts a thread into a thread group during thread construction. When you create a thread, you can either allow the runtime system to put the new thread in some reasonable default group or you can explicitly set the new thread's group. The thread is a permanent member of whatever thread group it joins upon its creation--you cannot move a thread to a new group after the thread has been created.
Offline markuskidd

Junior Member


Medals: 1



« Reply #45 - Posted 2003-01-16 16:51:11 »

Quote
but where does it say that a default threadgroup is created by the JVM on startup and the main thread is assigned to it?


On the same page as my previous links Cheesy

Quote
When a Java Virtual Machine starts up, there is usually a single non-daemon thread (which typically calls the method named main of some designated class).


That, combined with the knowledge quoted above that every thread is assigned a threadgroup, should pretty much close this case.

Someone posted code showing that a bunch of Threads that were created but weren't executed would cause a memory error, even if their references were lost. I will take a look, but I bet that they weren't garbage collected since they were in the default threadgroup, and thus it would still be possible to execute them.
Offline Kevdog

Junior Member





« Reply #46 - Posted 2003-01-16 18:06:16 »

Quote

Someone posted code showing that a bunch of Threads that were created but weren't executed would cause a memory error, even if their references were lost. I will take a look, but I bet that they weren't garbage collected since they were in the default threadgroup, and thus it would still be possible to execute them.


That's exactly it.  Started without a group they are put into the default ThreadGroup.  It is still possible to start them by running Thread.getCurrentThread().getThreadGroup()  then enumerating through the threads in the group to start it.  Basically it still has a reference to the Thread in the default threadgroup so it is never garbage collected.

It is the way it is supposed to work, but it is very misleading... not well documented... and can cause headaches (don't I know it!).  Basically just a "gotcha" when using the invokeXXX() functions.

There are only 10 types of people, those who understand binary and those who don't!
Offline princec

JGO Kernel


Medals: 362
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #47 - Posted 2003-01-16 18:22:42 »

Aye, that's what I was getting at. When you look at it in the wider context of JVM stability, and the even wider one of system stability, you'd be wondering why it isn't dealt with a bit more specifically...

Cas Smiley

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #48 - Posted 2003-01-20 17:31:51 »

Quote


It is still possible to start them by running Thread.getCurrentThread().getThreadGroup()  then enumerating through the threads in the group to start it.  Basically it still has a reference to the Thread in the default threadgroup so it is never garbage collected.


it is??

last time I looked, ThreadGroup only has methods for getting active Threads, not inactive unstarted Threads Tongue

(and there is a sun bug report already highlighting this flaw)

p.s.
While trauling the bug database, I was suprised to see the number of confirmed bugs in Thread, that Sun have acknowledged, but arn't about to fix. (something about a fundamental api flaw...  Wink)

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Pages: 1 [2]
  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.

atombrot (26 views)
2014-08-19 09:29:53

Tekkerue (24 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (14 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (60 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (30 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38

BurntPizza (67 views)
2014-08-03 02:57:17
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

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!