There were several threads about Swing GUIs in JMEDesktop not working on OS X some months ago. Has this been resolved? Sun has fixed some problems on XP/Vista as seen in latest version of the Java runtime for the PC.
monkeyman said:
Has this been resolved?
(if you are talking about JMEDesktop) No. And it probably will never be, if no Mac-user contributes some fixes :|
As a result of my personal research about the problem, I think that the fix have to be done in to LWJGL. Currently LWJGL for Mac and Linux uses AWT to provide the graphic context for rendering OpenGL. Only Windows implementation is totally native. I think that Mac OS X Java has not been implemented to permit 2 AWT threads running in the same instance of the JVM (as it happens when jMEDesktop is used), and that it causes serious event handling conflicts.
There should not be 2 AWT event threads. Why do you think this is the case, Ender?
FYI: from my testing/debugging it is the drop shadows that are from OSX (these have been included into the JVM itself and are almost impossible to remove --> see using cocoa/java)
I did find this --> http://lists.apple.com/archives/Java-dev/2007/Feb/msg00294.html However it is just for AWT windows not Swing Windows.
The one thing I CAN say conclusively is that there is some issue with borders (I get a memory lookup error whenever I run jME-Desktop on OSX), this may well be related to the shadow issue.
Here's something to try on your Mac:
http://www.fusion-laboratory.de/
See if the Fusinos "Flip-Box" example works. If it does, then the problem is somewhere in LWGL, because this example uses JOGL.
Thanks!
monkeyman said:
See if the Fusinos "Flip-Box" example works. If it does, then the problem is somewhere in LWGL, because this example uses JOGL.
The standard test works. Just a little delay before to complete rendering of information panels (after pressing flip button).
The enabled Java2D-OpenGL-pipeline does not work. Boxes do not flip and the area where they are does not update.
irrisor said:
There should not be 2 AWT event threads. Why do you think this is the case, Ender?
JMEDesktop requires an underlieing AWT environment. So I suppose it launch it when it requires any AWT class or method.
Mac OS X LWJGL implementation surely launches an AWT environment, because, as I said, it uses AWT to provide a graphic context (more preciselly JAWT, that is the technology currently reccomended by Apple considering that Cocoa Java is deprecated).
Considering that the authors of jMEDesktop (Galun is one, if I remember well) are not Mac Users, they probably have not provided any code to avoid to launch a second AWT environment under Mac OS X (moreover I do not know if it is possible).
This is what I think but I could be wrong. Though the suspect came to me when I tryed to launch LWJGL examples and jME examples using Soylatte, a Open Source port of Java 6 for Mac. Soylatte currently supports only X11 and not Aqua. When I did the test, I thought:
basixs said:
FYI: from my testing/debugging it is the drop shadows that are from OSX (these have been included into the JVM itself and are almost impossible to remove --> see using cocoa/java)
I did find this --> http://lists.apple.com/archives/Java-dev/2007/Feb/msg00294.html
That discussion regards the use of Cocoa/Java. Cocoa/Java is deprecated. Though LWJGL does not use Cocoa/Java; but JAWT. Only main window in a standard Java AWT application is an Aqua window. So the shadow in that case is controlled by Cocoa AppKit thread. The crash, in the case of that discussion, is caused by mixing Cocoa/Java GUI with AWT GUI.
OpenGL in LWJGL should not be handled by anything else but a Native window, though in the case of LWJGL for Mac it is handled by a AWT window.
Ender said:
Considering that the authors of jMEDesktop (Galun is one, if I remember well) are not Mac Users,
It mainly written by me :) (Galun made the drag'n'drop support) - and yes, I don't have a Mac; I only grabbed one several times to test it there, but could not get it to work in the short time I had a Mac for it.
Ender said:
they probably have not provided any code to avoid to launch a second AWT environment under Mac OS X (moreover I do not know if it is possible).
AWT handles it's thread on it's own. I seriously doubt that it really launches two threads. You can stop a JMEDesktop app in the debugger and look at the thread list to verify that.
Kevin Glass posted about a framework for the same purpose in that thread. You could check if that one performs well on Mac. If yes, we should probably find out why or switch techniques...
irrisor said:
Ender said:
Considering that the authors of jMEDesktop (Galun is one, if I remember well) are not Mac Users,
It mainly written by me :) (Galun made the drag'n'drop support) - and yes, I don't have a Mac; I only grabbed one several times to test it there, but could not get it to work in the short time I had a Mac for it.
Oops, probably I found Galun's name in the sources, and probably because of I know him (I have been in his project World of Mystery) I memorized him easier then you. Really sorry.
About the Mac, I understand that is impossible to debug an application for Mac if you do not have a Mac. Mine was not a critique. I could not ever critique anybody if he does not have a Mac. It was simply a consideration.
irrisor said:
Ender said:
they probably have not provided any code to avoid to launch a second AWT environment under Mac OS X (moreover I do not know if it is possible).
AWT handles it's thread on it's own. I seriously doubt that it really launches two threads. You can stop a JMEDesktop app in the debugger and look at the thread list to verify that.
Yes I am probably wrong in that (the presence of 2 AWT threads). I guessed my conclusions from the behaviour I saw when testing JMEDesktop on Mac. I am almost sure the problem is strictly related to the AWT Event Dispatch thread.
irrisor said:
Kevin Glass posted about a framework for the same purpose in that thread. You could check if that one performs well on Mac. If yes, we should probably find out why or switch techniques...
I will test it, thanks. Though I think that LWJGL implementation for Mac could be partially, if not totally, responsible for that. I am convinced that we should work on both the paths, if we want to resolve it all.
Unfortunatelly, JMEDesktop and LWJGL implementations are a litte too complex code for me to investigate deeper. I have not so much time and I am already busy with MD5 Reader 2.
Irrisor,
It looks like the test code in the thread you refer to solves the problem. Has anyone folded it into JMEDesktop? If not, I might have a little time to do so. I really need to have JMEDesktop work on all platforms.
Thanks!
I am pretty sure the conclusion to that conversation was that it wasn't able to help jME.
basixs said:
I am pretty sure the conclusion to that conversation was that it wasn't able to help jME.
no, not really. Kev only said that it would not change the conceptual problems with using Swing UIs in games. Using his technique instead of the current JDesktop could really help resolving the Mac issues. As I won't have the time for it, it would be great, monkeyman, if you would give it a try.
Hey irrisor,
I
I
Hey Momoko_Fan,
One of my applications works in two modes, where one mode is CAD-like, where updates to the screen only occur when some event takes place or the application window needs to be re-pained. However, in game-mode, then the usual game-loop applies. Then there is a separate issue when working on batteries, such that the ceiling of the frame-rate is progressively brought down based on remaining battery life. On the battery life stuff, I'll start a separate thread. On the hand, if you have any suggestions as to the best way of implementing the two operating modes I would be very appreciative.
so does this mean JMEDesktop is fixed yet for OSX? is there a new HelloJMEDesktop i can try?
the code linked here works; perhaps it can be integrated? or can someone show how to use this code with a gamestate?
if not, i’d like to add my voice to trying to prioritize GUI support in JME. the reason being… as far as i can tell there is currently no fully functional GUI option right now for OSX. and for a java game engine, methinks cross-platform support is crucial. to summarize: last i checked (1) JMEDesktop was not functional for OSX (correct me if i’m wrong!), (2) BUI is dead i think, right?, and (3) FengGUI still has significant problems (see this thread for example)
i’m not complaining… it would just be cool if i didn’t have to roll my own crappy checkboxes :)
l---l said:
if not, i'd like to add my voice to trying to prioritize GUI support in JME. the reason being.. as far as i can tell there is currently no fully functional GUI option right now for OSX. and for a java game engine, methinks cross-platform support is crucial. to summarize: last i checked (1) JMEDesktop was not functional for OSX (correct me if i'm wrong!), (2) BUI is dead i think, right?, and (3) FengGUI still has significant problems (see this thread for example)
i'm not complaining.. it would just be cool if i didn't have to roll my own crappy checkboxes :)
Well, I'm working on it. I got a little sidetracked this week, but I'll try and get something put together this weekend.
as far as i can tell there is currently no fully functional GUI option right now for OSX.
Umm, what about fengGUI?? The problem you posted about (in the other forum) seems like a logic issue (updating the openGL thread outside of openGL thread), not an issue with fenGUI. A LOT of people use it, including myself, and although it is a little more difficult to use than jME-Desktop in my opinion it is much more suited for a game GUI.
cool, thanks. your post in the other thread fixed the crashing i was having.