I’m just going to test the waters. What with my new experience of web start I wondering whether the distribution of native libraries is really something the user has to end up worrying about anyway.
That said, at the moment, I’m still of the opinion pure Java is still the ideal solution.
Kev
[quote]I’m just going to test the waters. What with my new experience of web start I wondering whether the distribution of native libraries is really something the user has to end up worrying about anyway.
That said, at the moment, I’m still of the opinion pure Java is still the ideal solution.
Kev
[/quote]
In my case its not the end user I’m worried about. I develop on a laptop, old rage mobility card. None of the opengl/gl4java/jogl demos have ever run well or consistanly for me.
[quote]That said, at the moment, I’m still of the opinion pure Java is still the ideal solution.Kev
[/quote]
This is more than an opinion, it’s the reason that Java exists. 
Otherwise there’s no need for a JVM - an “emulator”.
Now to the but…
I’m just using Jogl because my current Java application is to draw (hopefully fast) 3d graphics.
Furthermore I hope that Jogl will enter the standard Java edition one day; so this day using Jogl will mean to use pure Java.
[quote]First, let me say, YOU ARE A STAR.
[/quote]
Err. “God” actually
<----
[quote]Does the “user.home” still work as system property on all platforms?
[/quote]
It works on OS X, Windows and Linux.
[quote]* See, the green square is interesting. The Ship is a gif with a transparent background. The color of the background is a vibrant green (to help with screening it out). So, OSX isn’t supporting transparent gifs?
[/quote]
I’m using both GIFs and PNGs with transparency in my Swing app and they are working fine. How do you load the GIF? Do you transfer it to another image before using it? Maybe there is a step where the alpha is getting lost? This is interesting and something that we should figure out as it is likely to catch other developers as well.
Re:Write Once, Debug everywhere… You have to expect some of that. what are the chances that every JRE implementation is going to have (only) the exact same bugs? It’s no different than having bugs in different implementations of libc or such. Just look at the hell that configure scripts go through to test platform inconsistencies for C/C++ projects on unix.
If you go with JOGL I will be unable to test further until the next version of OS X is released 
I don’t have access to the developer preview required to run JOGL on the Mac. ($$)
Coo, I was under the impression the JOGL mac version was out, about and already in use… hmm…
The GIF is loaded using ImageIO I think, but it is then transferred into an accelerated image (which I believe has transparency currently set to BITMASK).
I’m only going for a sojourn (spelling?) in JOGL country. If its great, I might stay, if not, I’ll be hiking back over this way.
Kev
JOGL is available and working on the Mac… IF you have the developer preview of OS X 10.3. For that you need to pay… and since my company doesn’t develop for the Mac in particular they aren’t going to pay for the level of developer support that would get me access to that preview.
I think that transfer of the image from the one returned by ImageIO to the other is likely where the alpha is somehow lost. If you can send me a small example of how you do that I can submit it in a bug report to Apple, or we might uncover a flaw in your logic (perhaps the behavior is not clearly defined?).
You could compare with using the AWT image loading which will produce a managed (accelerated) image from the start.
This is the top of one of my classes. I’m at work right now, so this is from the CVS repository at java.net. I will be passing an image loaded from ImageIO into this method:
/**
* A set of utility methods to load images
*
* @author Kevin Glass
*/
public class ImageLoader {
public static int TRANSPARENCY = Transparency.BITMASK;
public static Image createMaskedImage(Image src) {
Image image;
GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
image = gc.createCompatibleImage(src.getWidth(null), src.getHeight(null),
TRANSPARENCY);
image.getGraphics().drawImage(src,0,0,null);
return image;
}
And using the returned image.
Kev
[quote]This is the top of one of my classes. I’m at work right now, so this is from the CVS repository at java.net. I will be passing an image loaded from ImageIO into this method:
/**
* A set of utility methods to load images
*
* @author Kevin Glass
*/
public class ImageLoader {
public static int TRANSPARENCY = Transparency.BITMASK;
public static Image createMaskedImage(Image src) {
Image image;
GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
image = gc.createCompatibleImage(src.getWidth(null), src.getHeight(null),
TRANSPARENCY);
image.getGraphics().drawImage(src,0,0,null);
return image;
}
And using the returned image.
Kev
[/quote]
Thats where your bug is!
You are assuming the image returned from createCompatibleImage() starts off totally transparent.
It does in the Windows JRE, but it is not guaranteed to.
(and looks like Apple decided to go with something different ::))
(incidentally, I ran into this same bug in J2ME 
The Sun MIDP reference implementation initialises images to White, where as the Nokia implementation initialises to Black ::))
You should change your load code to look something like this (so you are guaranteed to maintain the Alpha in the source image) :-
import java.awt.*;
import java.awt.image.*;
public class ImageLoader
{
final GraphicsConfiguration gc;
public ImageLoader(GraphicsConfiguration gc)
{
if(gc==null)
{
gc = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getDefaultConfiguration();
}
this.gc = gc;
}
public BufferedImage loadImage(String resource)
{
try
{
BufferedImage src = javax.imageio.ImageIO.read(getClass().getResource(resource));
//Images returned from ImageIO are NOT managedImages
//Therefor, we copy it into a ManagedImage
BufferedImage dst = gc.createCompatibleImage(src.getWidth(),src.getHeight(),src.getColorModel().getTransparency());
Graphics2D g2d = dst.createGraphics();
g2d.setComposite(AlphaComposite.Src);
g2d.drawImage(src,0,0,null);
g2d.dispose();
return dst;
}
catch(java.io.IOException e)
{
return null;
}
}
}
Updated, new version on webstart.
Now I’m going to try the JOGL stuff…
Kev
I still get the green background… I’m looking into it…
I have filed a bug report with Apple (Problem ID# :3338311)
It looks like they aren’t handling/supporting the transparency properly.
Now… can we do something to narrow down the full screen mouse event issue? If I can get a small test case to the Apple guys they are much more likely to fix it.
I’ve knocked together this demo for full screen, source included:
http://www.cokeandcode.com/fsdemo.zip
Wasn’t sure if ZIP will be ok? Don’t you MacOS guys use sit or something?
Can you check if that has the same problem,
Kev
Ah thanks, that makes the bug reporting go so much faster. I’m currently running a developer preview of the next 1.4.1 JRE update… so it is good do get the reports in ASAP in case it is something they are able to fix before the update is released.
StuffIT (.sit) can handle pretty much anything I’ve ever thrown at it so far, .zip, .gz, .tar, .sit.
Ok… I will try later tonight to investigate the full screen issue, try to find a workaround and submit a bug report.
Ok… I just submitted the bug without looking for workarounds - no time. Problem ID# 3338508
Thanks for the test case. Apple loves having an executable test case.
Thanks for chasing this, it’d be nice if it gets sorted out.
I’ve played a bit with JOGL, and things seem to be going ok, although people are a little ropey about details at the moment.
Just thought I repeat a concern that got raise over the JOGL forum. Jumping to something like JOGL was (for me at least) a way to get accelerated alpha on multiple platforms. Seems like MacOS is lagging somewhat behind with its JOGL impl however, so I’m not sure whether its such a interesting play afterall…
I might start a second topic here to discuss the pros/cons of moving from pure java to one of the newer APIs for 2D work, if anyones interested…
Kev