Jme3 Canvas on Mac OS X

I’m not sure if this is a problem with Jme3, Java Swing, Mac OS X or my architecture.

My architecture works fine on Windows 7:
I have a Java windows application with a JFrame as the starting class.
In the JFrame is a TabbedPane. The first tab is a JSplitPane.
Jme3 Canvas runs in the top pane of the split pane, I presume, as its own process.

I can run 3d simulations in jme3 from the first tab. Looks great.
I can click on another tab and edit data about the simulation.
I can click back to the first tab and run the simulation with the changed data.

When my friend tried this program on his Mac, the Jme3 Canvas would not yield. It stays on the screen even after my friend clicked on another tab. My friend cannot see the information in the other tab.

I tried…………………………
I added some code to set the canvas to invisible when anyone clicks on another tab. Doesn’t help.
I added some code to stop and restart the Jme3 application.
This causes a noticeable pause when switching tabs.

Any ideas about why the Canvas remains visible when running under Mac OS X but not Windows 7?

Any suggestion for a fix that does not entail rewriting the entire user interface?

Older versions of java/swing had problems mixing heavy weight and light weight components. So a first sanity check is wich java version is used on the Mac.

Well, I went out and bought a brand new Mac mini running the latest OS X Yosemite.
I downloaded JMonkey SDK for the mac and transferred my development code to it. I ran the code from there. And I was horrified at what I saw. The issue I raised with the Jme3 canvas is now secondary.
But it is still there. On start up, the canvas does not appear to be in its assigned split pane. Instead it fills the upper left part of the JFrame. Since there is a tabbed pane/split pane in the JFrame, the canvas is hiding the tabs. After any kind of resizing, the canvas appears to retreat into its assigned split pane. But it remains on the screen when I select another tab. So I can’t work in any of the other tabs.

Now for the worse part. (This has nothing to do with Jme3)
Yosemite has only one default font system. Common text is so small that the apple web sites are filled with postings complaining about it. The only workable fix so far is to change the scale of the monitor, thus increasing character size at the expense of the nice resolution we all paid so much to get.
And there is more. The default Java Look and Feel is a farce. I have to stop typing or I will start cursing.

I made a alternative to jme Canvas for an other user (tested on linux, windows and mac (not by me)).

source : davidB/jme3_ext_swing
binary : jme3_ext_swing

there are a sample code under src/test. I can write few lines of doc if you’re interested.

I suggest simply using AwtPanels instead of the canvas which will be deprecated in future versions of jME anyway.

Is there any issue with AWT panels that you were trying to fix?

Thanks. I’ll give it a try.
With respect to the suggestion to use AWT panels, I though Swing were the preferred design elements. I think of AWT as “going backwards”. No?

Swing is AWT, the AwtPanel is a normal lightweight component.

IIRC, we already had this conversation.

“AwtPanel extends Canvas” and Canvas is not a “lighweight component” in java terminology (eg: Bug ID: JDK-7012806 Cannot mix lightweight and heavyweight components in an undecorated JFrame )

I don’t have issue with AWTPanel, but @AXELTOPOLINO had issues with AWTPanel ( [Forum] My topic is not available at page 3 only?! - Troubleshooting / General Help - jMonkeyEngine Hub ) Remember, he tried to fork AWTPanel and backport from master some changes.
I created jme3_ext_swing to let it try with a component based on JPanel and not Canvas. And he created a minecraft model editor with it.

The issue is that there’s no way of having active rendering with Swing / light-weight components. With AWT panel / Canvas you can use BufferedStrategy which is very fast. With JPanel you must implement JPanel.paintComponent(), Swing will only call it when it feels like it, and jME3 will need to be synchronized to that. This is why you had all those lag issues in the thread … once the viewport gets too big, the costs of conversion become very high.

I don’t understand what you call “active rendering” ?
In my implementation the SceneProcessor call “JPanel.repaint();” (who call paintComponent()) for every frame that is different than the previous one. By default at 30 fps.

repaint() doesn’t immediately paint the panel, it paints it next time Swing thinks its got time for that.

You can learn more about it here:

But it turns out I was actually wrong … It is possible to have active rendering on Swing components. I might end up making something like SwingPanel which would do it via active rendering + light-weight component, which would get the benefits of both options. In that case, there won’t be any need for AWTPanel anymore.

Oh boy,
Now I am confused.

My problem only shows up on Mac OS x Yosemite. I suppose that could be coincidence, but I have been developing this program for over a year in many variations on my windows machine without seeing the problem being discussed here. No wait, I did have a problem. At one point I had to move several chunks of code that modified the meshes into the Jme3 application thread. But that probably has nothing to do with the subject of this thread.

I’m thinking of a new approach. Display the canvas in a JFrame with a JSplitScreen (no TabbedPane). Use pop-up windows for the other data. I already use some popup windows for data entry and that seems to work well on both Windows and Mac.

As you can tell, I am afraid to start messing with the Jme3 Canvas.

Just use the AwtPanel.

This is just closure (I hope) on my issue of the behavior of the Jme3 canvas in a Swing window on the Mac. I didn’t thank all those who responded with suggestions. So thanks. I decided to completely redesign my simulation application. Now I am getting what looks like correct behavior on Windows and Mac. This is what I did. I put the default Jme3 canvas in its own JFrame which I called the “Simulation Window”. Then I put all the swing buttons, drop down boxes and controls in a separate JFrame that I called the “Console Window”. When the application is started, both windows are created and placed on the screen one below the other. The user can move each around separately. I remember seeing this kind of design in the past and its behavior will be reasonable for my target users.