Hi all,
Just FYI, as the subject reads, Mac OS Java Update 2 ( 1.6.0_20) breaks JLWGL applets, (at least yours at: http://lwjgl.org/applet/, only one I know of but I came across this issue with JOGL and we were looking to perhaps switch over to LWJGL and I see it here now too)
To be more specific;
Open applet page with default Java security settings:
In Safari
you get "Error. Click for details" in the applet and this in the Java console:
java.lang.SecurityException: attempted to open sandboxed jar http://lwjgl.org/applet/lwjgl_util_applet.jar as a Trusted-Library
at com.sun.deploy.security.CPCallbackHandler$ParentElement.checkResource(CPCallbackHandler.java:354)
In Chrome
you just get the same error
In FireFox, it runs (ignores security settings? not sure how it could)
If the Java Pref. security settings are disabled (labeled "insecure" in the UI :-():
In Safari and Chrome:
You get no errors in console and even run-time output (frame rate, etc) but NO render, just blank white page.
In FireFox:
Again it seems to run fine
This is a bit of FYI, but also I'm following this closely as this is a very serious issue for us, as we have commercial products on Java+OGL+Applet stack.
Good luck sorting that out :\
Strange .. we specifically updated our stuff to work with all the new u20 shit... works on windows using Java Plug-in 1.6.0_20
Any other mac users with same issue?
Yes, here (http://www.javagaming.org/index.php/topic,22447.0/topicseen.html).
Hi,
We also have problems with our applets on Macs since Java update 2 (1.6.0_20). Here are the noticeable problems observed:
Non-modal windows appear behind the browser window.
Double-buffering does no seem to work.
The animated Java logo is now very jerky (used to turn smoothly)
The same application launched with Java Web Start runs perfectly.
The application can be tested here (press ok if a login prompt appears):
Java applet: http://jmap3.k2geospatial.com/montreal_applet/
Java Web Start: http://jmap3.k2geospatial.com/montreal_jws/dockingClient.jnlp
Our applications running in applets use the new plug-in 2 with JNLP files.
I posted on Apple support forums:
http://discussions.apple.com/thread.jspa?threadID=2460856&tstart=0
Although our applications are not games, I thought it would be interesting to post this here because I think we might be experimenting the same problems. You may want to add your voice to mine on Apple forums.
Regards.
Jean-Robert
Its pretty clear what the cause of these problems are, with java plugin2 apple now force offscreen rendering and render using their own coregraphics api. This has the advantage of allowing html content to overlap the applet and better integrate it into the page.
However this has had the effect of pretty much breaking the frame rate on every type of applet (including PulpCore) and has totally broken all types of OpenGL Applets (JOGL & LWJGL).
Only solution atm to these problems is to fallback to the old java plugin1 (not supported by Chrome, which always just uses plugin2) to do this you go to the java control panel and disable out of process java applets.
My applets are also broken on Chrome and Firefox since this last java update on mac.
With luck they still works with Safari/Webkit, so I can still develop on mac. But it's not a viable solution to just tell Chrome/Firefox users to start Safari just to view the applet (frankly I don't expect much people to do that).
Did anyone know if there is some news/talks/works around Apple, Chrome or Firefox related solve this problem ?
I think this problem has been solved, I currently dont experience any problems on MAC.
test case: http://have2chat.net/fvf (http://have2chat.net/fvf)
Granted I have only tested in safari and firefox, but i assume it would be the same for chrome
Chrome on Mac still has troubles displaying LWJGL applets. It appears to load them, but then can't display the GL context. Every other browser on the Mac seems to work fine though, so I'm not sure if it's an LWJGL problem or a Chrome issue. Also, normal Java applets in Chrome show up just fine.
As I understand it plugin2 on mac has broken opengl applets (lwjgl and jogl) as well as crippled performance on all other applet libraries (java2d, pulpcore, etc). This is because they now force all rendering to an offscreen buffer and then draw it through CoreGraphics api, this allows other normal html stuff to now overlap applets and help better integrate it into the page.
To check you have plugin2 enabled you have to make sure 'Run Applets in their own process' is checked in the java control panel. By default firefox and safari use plugin1, this should explain why applets still work there. Chrome on the other hand can't use plugin1 and always (regardless of the control panel setting) uses plugin2, this should explain why it fails on Chrome.
I downloaded chrome for mac
and as you said java doesnt work.
My applet works regardless of the version selected in firefox and safari.
Something else interesting about google chrome is that you can place a Div over an applet.
I ran the facebook version of my applet and the menu popups covered the applet (non OpenGL applet) fine without error.
@bobjob just curious which version of MacOS X are you using? (10.6 update 2?)
sorry I just noticed, that safari doesnt work with OpenGL if you run the applet in its own process. Im using my sisters laptop, Im not used to mac :-[
edit: I downloaded the latest firefox for mac, still seems to run the old java plugin regardless of what is setting is on in the "java prefrences".
Is there a way to detect if plugin 2 is running? Then I could at least copy the color buffer to a raster and paint it in a canvas.
Quote from: bobjob on September 16, 2010, 10:39:35
test case: http://have2chat.net/fvf (http://have2chat.net/fvf)
Works only on safari for me. I have Mac OS 10.6.4, and applets are broken since las java update (shipped in 10.6.3 if my memory is good).
I have the lastest firefox 4 beta 6, it don't starts the applets at all. It just stays at the java logo and nothing appends then.
I'll try to reinstall it. Which version of firefox are working for you ?
On chrome, nothing is rendered. My applets just seem to runs fine in background (like elias said) but nothing is rendered on the page.
EDIT: I've just re-installed firefox from scrash (firefox 4 beta 6), and applets now starts and runs in background but like Chrome nothing is rendered onscreen.
EDIT: I've filled a bug for Chrome http://code.google.com/p/chromium/issues/detail?id=56008 (http://code.google.com/p/chromium/issues/detail?id=56008)
I have been fiddling with this problem.
Made a semi fix:
have2chata.net/fvf/ (http://have2chata.net/fvf/)
Fixes needed:
* Mouse setGrabbed doesnt work.
* Will be applied to all mac applets (I still dont know how to detect ONLY plugin2)
* Need to run it in its own Thread so that graphics in the Mac applet, are not at all related to the normal applet performance.
* Should probably apply a version check as well, as Im assuming that a later java update with plugin2 will support OpenGL.
Current Version:
package ...;
import java.awt.Canvas;
import java.awt.Dimension;
import java.awt.Graphics;
import java.awt.Point;
import java.awt.Rectangle;
import java.awt.image.BufferStrategy;
import java.awt.image.BufferedImage;
import java.awt.image.ComponentSampleModel;
import java.awt.image.DataBuffer;
import java.awt.image.DataBufferByte;
import java.awt.image.SampleModel;
import java.awt.image.WritableRaster;
import java.nio.ByteBuffer;
import org.lwjgl.BufferUtils;
import org.lwjgl.opengl.Display;
import org.lwjgl.opengl.GL11;
/** Canvas that will take up the whole frame*/
public class ResizableCanvas extends Canvas implements Runnable {
private boolean resize = true, macFix;
private BufferStrategy buffer;
public BufferedImage b;
//int texture;
private ByteBuffer data;
private SampleModel sm;
private long lastResize;
private int gameWidth, gameHeight;
private ByteBuffer runData;
private SampleModel runSM;
private Thread drawThread;
public ResizableCanvas() {
super();
if (System.getProperty("os.name").toLowerCase().startsWith("mac")) {
String prop = System.getProperty("java.rmi.server.RMIClassLoaderSpi");
if (prop != null && prop.contains("plugin2")) {
//SHOULD ALSO DO A VERSION CHECK ONCE VIABLE OPENGL VERSION IS RELEASED
macFix = true;
}
}
}
public void init() {
validate();
requestFocusInWindow();
if (macFix) {
createBufferStrategy(2);
buffer = getBufferStrategy();
setIgnoreRepaint(true);
}
fixSize();
}
public boolean requireMacFix() {
return macFix;
}
public boolean checkResize() {
if (resize && lastResize + 500 < System.currentTimeMillis()) {
if (!macFix) validate();
fixSize();
resize = false;
try {
Display.setParent(this);
} catch (Exception e) {
e.printStackTrace();
}
return true;
}
return false;
}
private void fixSize() {
gameWidth = getWidth();
gameHeight = getHeight();
if (gameWidth <= 0) gameWidth = 16;
if (gameHeight <= 0) gameHeight = 16;
if (gameWidth % 4 != 0) gameWidth += 4 - (gameWidth % 4);
if (gameHeight % 4 != 0) gameHeight += 4 - (gameHeight % 4);
if (macFix) {
data = BufferUtils.createByteBuffer(gameWidth*gameHeight*3);
b = new BufferedImage(gameWidth, gameHeight, BufferedImage.TYPE_3BYTE_BGR);
sm = new ComponentSampleModel(DataBuffer.TYPE_BYTE, gameWidth, gameHeight, 3, gameWidth*3, new int[]{0,1,2});
lastResize = System.currentTimeMillis();
}
}
public void run() {
try {
byte bytes[] = new byte[runData.capacity()];
runData.get(bytes);
runData.position(0);
DataBuffer d = new DataBufferByte(bytes, bytes.length);
b.setData(WritableRaster.createWritableRaster(runSM, d, new Point(0,0)));
Graphics g2 = buffer.getDrawGraphics();
g2.drawImage(b, 0,b.getHeight()-1, b.getWidth(), -b.getHeight(), null);
if (g2 != null) g2.dispose();
if (!buffer.contentsLost()) buffer.show();
} catch (Exception e) { e.printStackTrace();}
drawThread = null;
}
public void doMacFix() {
if (macFix) {
if (gameWidth > 16 && gameHeight > 16) {
if (drawThread == null) {
try {
GL11.glReadPixels(0, 0, gameWidth, gameHeight, GL11.GL_RGB, GL11.GL_UNSIGNED_BYTE, data);
runData = data;
runSM = sm;
drawThread = new Thread(this);
validate();
drawThread.start();
} catch (Exception e) { e.printStackTrace(); }
}
}
}
}
public void destroy() {
if (macFix) {
Thread t = drawThread;
if (t != null) {
while (t.isAlive()) {
try {
Thread.sleep(1);
} catch (Exception e) {}
}
}
}
}
public void setSize(Dimension size) { super.setSize(size); resize = true;}
public void setSize(int x, int y) { super.setSize(x, y); resize = true; }
public void reshape(int x, int y, int width, int height) { super.reshape(x, y, width, height); resize = true; }
public void setBounds(int x, int y, int width, int height) { super.setBounds(x, y, width, height); resize = true; }
public void setBounds(Rectangle r) { super.setBounds(r); resize = true; }
public void resize(Dimension size) { super.resize(size); resize = true; }
public void resize(int x, int y) { super.resize(x, y); resize = true; }
}
How to use:
create the custom canvas
canvas = new ResizableCanvas();
init the canvas after Display.create();
Display.create();
canvas.init();
make sure to call doMacFix after update
Display.update();
canvas.doMacFix();
also to prevent any errors, make sure to call destroy before Display.destroy();
canvas.destroy();
Display.destroy();
optionally: to check if the fix is needed. you could also use this to force a Display window, instead of an applet.
canvas.requireMacFix();
The other methods included I use in order to handle my applet on resize.
Some problems:
* You will notice alot of stuff ups when the applet tries to grab the mouse, do this by pressing the esc key on the main menu, or seletecting the close menu button.
* In safari mouse movements only seem to regester if mouse key is down.
Edit: And can someone pleeeeease tell me a accurate way to determine which plugin version is running, thanx.
oh, really cool stuff, if you manage to find a fix/workaround for this problem then your a genius :)
Quote from: bobjob on September 19, 2010, 07:58:17
Edit: And can someone pleeeeease tell me a accurate way to determine which plugin version is running, thanx.
I haven't got a mac so not really got anyway to try this, but I am aware that the DeployJava.js (http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html) has a method that can detect through javascript if plugin2 is running 'isPlugin2()'. Human readable version of the script is found here (http://www.java.com/js/deployJava.txt). Hopefully this'll allow you to find a java method to detect plugin2.
Quote from: kappa on September 19, 2010, 09:28:23
oh, really cool stuff, if you manage to find a fix/workaround for this problem then your a genius :)
This isnt a long term viable solution as it has a incredible slow frame rate, but displaying something is infinetly more than nothing.
Quote
I haven't got a mac so not really got anyway to try this, but I am aware that the DeployJava.js (http://download.oracle.com/javase/6/docs/technotes/guides/jweb/deployment_advice.html) has a method that can detect through javascript if plugin2 is running 'isPlugin2()'. Human readable version of the script is found here (http://www.java.com/js/deployJava.txt). Hopefully this'll allow you to find a java method to detect plugin2.
I will look into it, I might print out the complete list of properties in both versions and see if i can find some useful variations.
Also keyboard seems to be working fine.
So If anyone only uses keyboard in there applets, in that instance this fix should be enough.
Some other strange behaviour that I cant seem to fix, Safari Mouse events seem to work fine if the java console (???) has focus.
Quote from: bobjob on September 19, 2010, 09:44:25
This isnt a long term viable solution as it has a incredible slow frame rate, but displaying something is infinetly more than nothing.
Another thing you could do is just not use Display.setParent() if plugin2 is detected on mac, that way when the applet is run you'll just get a popup LWJGL window. Think that should workround the applet offscreen rendering thing and just work at normal speed.
Quote from: kappa on September 19, 2010, 10:06:16
Another thing you could do is just not use Display.setParent() if plugin2 is detected on mac, that way when the applet is run you'll just get a popup LWJGL window. Think that should workround the applet offscreen rendering thing and just work at normal speed.
yeah thats definetly the best solution for performance.
Ok for those interest I think the Property to find out if your running plugin2 on mac is "java.rmi.server.RMIClassLoaderSpi"
if the value is not null && contains plugin2, then it should be enough to detect that plugin2 is running
Property check applet: have2chat.net/fvf/prop_test.html (http://have2chat.net/fvf/prop_test.html)
Edit:
Updated the source code.
- Safari.
sadly the Mouse functions normally only (aswell as setGrabbed()) as long as the java console has focus.
- Chrome
Mouse.setGrabbed(true) causes errors.
I Think I will leave it there. I'v done the most that I can without going through the LWJGL source code.
Now Im off to watch the first two episodes of Vampire Diaries season 2 JOY!
one other thing I was thinking, with the new plugin its possible to use JNLP, for cache and such.
Is it possible to pass vm_arguments?
If so then would it be possible to pass an arguement not to render to an offscreen buffer?
if I dont get a response Ill look into it, will fiddle around on it tomorow night.
Quote from: kappa on September 19, 2010, 10:06:16
Another thing you could do is just not use Display.setParent() if plugin2 is detected on mac, that way when the applet is run you'll just get a popup LWJGL window. Think that should workround the applet offscreen rendering thing and just work at normal speed.
Quote from: bobjob on September 19, 2010, 10:39:30
Ok for those interest I think the Property to find out if your running plugin2 on mac is "java.rmi.server.RMIClassLoaderSpi"
if the value is not null && contains plugin2, then it should be enough to detect that plugin2 is running
Thanks for the suggestions :)
The detection see to be fine, I have "java.rmi.server.RMIClassLoaderSpi:: sun.plugin2.applet.JNLP2RMIClassLoaderSpi" with plugin2
I think I'll go this way if plugin2 takes too much time to be fixed (I don't think that Apple is very reactive).
Hey guys I made a class that will run the canvas in a window if the new plugin is detected.
its attached to this post.
as before, test case: have2chat.net/fvf (http://have2chat.net/fvf)
Keys 1, 2 switch between display types
This will help you if you dont have access to a Mac, and would like to run LWJGL but cant debug it.
Usage:
instead of creating a new Canvas().
use:
rContainer = new ResizableContainer(false);
Canvas canvas = rContainer.getCanvas();
the boolean variable in the ResizableContainer constructor is if you will
be using resizable applets (set your applet size in percentage) then set it true.
setup your canvas as usual (as if it was to run in an applet) before attaching the display,
but instead of using Display.setPerant(...);
use:
rContainer.attachDisplay();
and once every game cycle call this method
rContainer.checkResize()
you may notice that checkResize() returns a boolean value, I use this to
reset the GL viewport if needed.
you probably wont need the return value if you dont use resizable applets.
Other useful methods.
in order to get the current width and height use:
Canvas canvas = rContainer.getCanvas();
if (canvas != null) {
canvas.getWidth();
canvas.getHeight();
}
if the canvas is "null" then you will need to get the current DisplayMode, as it means you are running in fullscreen mode.
to set canvas screen mode if possible:
rContainer.setFullscreen(null); //SWITCH BETWEEN FULLSCREEN / APPLET
rContainer.setWindow(); //SWITCH BETWEEN WINDOW / APPLET
*note that this wont be the final version, as soon as a opengl supported mac update is released so will this class.
This issue should now be fixed in latest nightly builds of LWJGL, see this thread (http://lwjgl.org/forum/index.php/topic,4023.0.html) for me info.