Skip to main content

Testing

1 reply [Last post]
francoislionet
Offline
Joined: 2008-01-13

Hi guys,

This post is about nothing really, but I would like to share my experience of today.

I am working with Sonic solutions (the makers of Scenarist) as they might publish my product. My product is a game and application creator, so basically, it is a runtime that interprets a compiled file with images and sounds.
So today, I had a day in Sonic's testing room, and I could test my application on all the players they have there.

So far, I only had my app working in WinDVD on my PC. WinDVD is not really good for testing, as it uses Personal Basis Profile 1.1 and not 1.0 like the others. So for example, I was printing the stack when a crash occured, and this is not supported in PBP1.0.

At first, as I expected, my applications crashed badly. The first error I had was an illegalaccess when loading the images. What I did, was a createimage("/image.png"), with image.png in the root of my jar file. After struggling for a while, I found out that you should not put the slash before the name of the image for it to work. But this worked in WinDVD.
What is more strange is that I do a getressourceasstream and this one NEEDS a slash, or it does not work. On the same players!

I had another crash on one player, and found out that the system.getproperty("bluray.rccapability.release") that you call to know if the keylistener receives key release events, returned null on this player!!
So I have a question for the gurus : if this getproperty returns null, should I assume that the keyrelease events are sent or not?

So I had simple applications working on nearly all the players. And actually I was surprised : it did not take too long to load, and it worked quite well (my application is rather big).

Then I tried more complex games. Like with 100 different small images to load. And a large scrolling screen displayed.
Profile 1.1 players ran that easily, loading time was reasonable (like 10 seconds), and the scrolling was fairly OK (like 6/10 fps)
Profile 1.0 players, I had my application work on half of them, some players being really quick in loading the data, as fast as the profile1.1. Some were slower (maximum was 20 seconds, with is OK for a profile 1.0 player)(profile 1.0 owners should not expect to have complex BDJ anyway).
The PS3 ran my application like a breathe. Loading time was seconds, and the frame rate was the original one, 50 fps. Really cool.
BUT, the PS3 did not respect the BluRay specs!!! The bdjo file stated that the resolution mode for the Java app was 960x540 (QHD), and the PS3 displayed it in FullHD 1920x1080. All the other players displayed it in QHD. This is really annoying, Sony does not respect his own specs!!!

So I have a question : is it possible to detect on boot of the jar, the current resolution mode? Like HD or QHD? If I detect HD for an application with a bdjo set to be QHD then I could zoom the graphics by two when drawing them on the screen...

So, this is my experience of today. I was actually pleasantly surprised by the players. They are not so bad after all. They can run my complex application (the size of the jar file of my application is about 300 k) with no problem, even profile 1.0 players.

I think this is good news for all of us. We can acheive good things on those players, even the profile1.0 ones.

Francois

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Bill Foote

bd-j-dev@mobileandembedded.org wrote:

> At first, as I expected, my applications crashed badly. The first error I had was an illegalaccess when loading the images. What I did, was a createimage("/image.png"), with image.png in the root of my jar file. After struggling for a while, I found out that you should not put the slash before the name of the image for it to work. But this worked in WinDVD.
> What is more strange is that I do a getressourceasstream and this one NEEDS a slash, or it does not work. On the same players!

Hey Francois,

That part is actually in the Java spec - Class.getResourceAsStream() views
the world as a filesystem determined by the classpath. So, for this method,
a file name starting from "/" makes sense, because the root of this ersatz
file system is the classpath.

createImage() takes a file in the "real" filesystem. By not starting
with a slash, you read out of the application's default directory, which
I believe for BD-J is defined to be the base directory of the JAR file
containing the xlet.

> I had another crash on one player, and found out that the system.getproperty("bluray.rccapability.release") that you call to know if the keylistener receives key release events, returned null on this player!!
> So I have a question for the gurus : if this getproperty returns null, should I assume that the keyrelease events are sent or not?

You should conclude that the player was made before the system property was added
to the spec, and therefore make the most conservative assumption you can: You'll
definitely get a KEY_DOWN event, but the rest of the behavior can be anything
else that's valid.

> So I have a question : is it possible to detect on boot of the jar, the current resolution mode? Like HD or QHD? If I detect HD for an application with a bdjo set to be QHD then I could zoom the graphics by two when drawing them on the screen...

I know we got QHD working on a PS/3, but I don't think that demo is
out on the repository yet. I'll make inquiries.

Cheers,

Bill

---------------------------------------------------------------------
To unsubscribe, e-mail: bd-j-dev-unsubscribe@hdcookbook.dev.java.net
For additional commands, e-mail: bd-j-dev-help@hdcookbook.dev.java.net