FX Experience Has Gone Read-Only
I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!
tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.
by Richard Bair | Feb 11, 2013 | News
We’ve been making progress in getting JavaFX open sourced. I wanted to take a few minutes to include this information on fxexperience (since many of you aren’t watching the mailing list). Oh, and you might want to read this one, there is some big news at the end of the post 😉
Late last year at JavaOne our Executive VP Hasan Risvi announced at JavaOne that we would be open sourcing all of JavaFX by the end of 2012. We didn’t quite make that (actually, it was a pleasant surprise to me as the announcement was made as much as to everybody else in the audience!). We quickly got into gear and started the substantial effort that goes into open sourcing each project. We have a lot of code. The following projects have already been open sourced as of this writing:
(more…)
by Richard Bair | Dec 18, 2012 | News
BrickBreaker running on a Raspberry PI
Today Oracle has released the first JavaSE 8 + JavaFX Developer Preview. This is really exciting for anybody who’s wanted to try out the $35 Raspberry PI ARM mini-computer (and I do mean mini!). Incidentally, anybody who picks one up really needs to get the Pi-Bow enclosure for the PI — I got one yesterday and highly recommend it!
JavaSE is a HotSpot based VM, so it is really quite zippy. I did some timing calculations on my PI this morning based on the prime number test provided in this Raspberry PI Java forum posting. Yes, there is a new Java category on the Raspberry PI forums, do visit and leave your experiences there :-). Anyway, I ran both Java and GCC version 4.6.3 with -O2 performance optimization enabled.
| Test |
Real |
User |
Sys |
| JavaSE 8 (build 1.8.0-ea-b36e) |
0m7.830s |
0m4.970s |
0m2.840s |
| GCC 4.6.3 (Debian 4.6.3-12+rpi1) |
0m7.716s |
0m4.990s |
0m2.700s |
| GCC 4.6.3 (Debian 4.6.3-12+rpi1) -O2 |
0m6.361s |
0m3.940s |
0m2.400s |
I find the results really impressive, because basically the difference seen between Java and native is just due to the startup costs. Which means that Java is a really great choice for developing applications that will run on the Raspberry PI. Java also represents (to my knowledge) the first VM stack to optimize for hard float on ARM v6.
I couldn’t help myself though, I cranked up the test to find all prime numbers below 50,000 to see if the startup costs in fact are the difference between the JVM and native code. Below are the results. As you can see, HotSpot is faster than native code!
| Test |
Real |
User |
Sys |
| JavaSE 8 (build 1.8.0-ea-b36e) |
1m37.808s |
1m25.570s |
0m12.000s |
| GCC 4.6.3 (Debian 4.6.3-12+rpi1) |
2m18.875s |
2m7.390s |
0m11.1300s |
| GCC 4.6.3 (Debian 4.6.3-12+rpi1) -O2 |
1m42.166s |
1m31.206s |
0m10.580s |
I wrote a quick JavaFX application this morning and tried it out. A couple things to make sure you note!
- jfxrt.jar is not on the classpath by default (yet). So be sure to include it!
- -Djavafx.platform=eglfb must be specified. If not, it won’t run.
- Ahem. There appears to be no way to kill an FX app, unless you can SSH into your box or switch to another terminal. Or have your app make sure it has an exit button. But then, when playing BrickBreaker, who’d ever want to stop?
None of the flags used in javaFX on the command line are “public API” and may go away in the future, but this particular flag is likely to be around for a while. It lets you choose which version of glass to run with. On Raspberry PI, right now, the only option is eglfb (which makes you wonder why we require you to specify it on the command line. There are some questions that we just shouldn’t ask ;-)). Basically EGLFB runs OpenGL on the frame buffer directly, meaning that it wants to own the entire screen. This is great for Kiosks and media centers and such, but not so good for normal X11 usage. Hopefully the X11 usage shows up sometime soon, but in the meantime, JavaFX will own the display.
You should go read the developer preview documentation and also Stephen Chin’s blog on PI. JFokus has a Raspberry PI hands on lab, which is already fully booked, but I’m betting you can get Simon Ritter to give you some material if you want to try at home :-).
Have fun hacking over the holidays!
by Richard Bair | Nov 5, 2012 | Uncategorized
I am presently typing away on a new Retina Display MacBook Pro, and it is an interesting experience. The visual clarity is stunning. It is akin to the feeling of going from Atari to Nintendo, or Nintendo to Nintendo 64, or standard def to Hi-Def. I just didn’t realize what kind of poor quality I was looking at before.
But it isn’t all rainbows and sunshine. All of Apple’s applications look stunning. But many 3rd party apps look bad (including Java apps), and web browsing is horrific. The problem is high-DPI, and how Apple went about solving the HDPI problem.
On Retina MacBook Pro displays, there are some 220 pixels per inch. If you rendered everything 1-to-1 on such a display, the text (and everything else) would look tiny. You’d need a bionic eye (or a magnifying glass) to read anything on the screen. Or at least, really young eyes. So instead, everything needs to be scaled up.
For vector graphics and text, this is pretty straightforward. You just scale things up and render at the higher resolution and things look great. But for images it isn’t so simply. Scaling images produces a blurry result. And that, in fact, is the experience of using a retina display when browsing websites. You will come to some websites where the text is crisp and the images are all blurry. Other websites have some crisp text and some blurry text, ostensibly either because intentionally or unintentionally the web site is rendering text to an image and then the image is being scaled. And it makes for a horrendous user experience.
In Apple’s applications (starting with the iPhone and iPad with their retina displays), the solution to the problem is for the application developer to supply two images instead of one for each image asset. For example, the splash screen will be supplied with two images, one at normal resolution and one at 2x the resolution. The files are named the same but the 2x one is named according to some convention, such that at runtime the platform will lookup the 2x version on retina behind the scenes. In such a way, your application says “fooImage.png” but “fooImage@2x.png” is looked up instead when on a machine with a retina display.
At the moment, all Java applications (including FX) are pixel-doubled, such that everything (text, images — everything) are doubled and look blurry. But since I’m going to be working on a retina MacBook for the next several years, we’ve got to fix this situation. Driving me UP THE WALL. Our plan is to follow Apple’s lead, and automatically attempt to load the @2x image if one is available, and to otherwise signal to Mac OS X that we’re a high-DPI aware application and it shouldn’t pixel double everything on us.
One thing to be aware of here is that Canvas and ImageWriter are not going to be able to deal with high-DPI right off the bat. Your application is written as if it is on a normal display, but Canvas ends up needing to be pixel doubled. In the future we’ll add API so you can detect this situation and draw into a larger canvas (or automatically scale everything up for you).
I can’t wait for FX to be in hi-res!
by Richard Bair | Oct 19, 2012 | Uncategorized
After a ton of work and navigating the legal bureaucracy, Scott Kovatch on the JavaFX team has successfully put the first JavaFX Application (that we know of) into the Mac App store! It was particularly fun to read James Gosling’s ringing endorsement. As most of you probably know, Ensemble is our sampler application which has all the Javadoc and a hundred or so samples of everything from animations to controls to binding to 3D. It is also the application we will continue to build up as we go along. We originally released it with JavaFX 2.0, and the team has been adding content to it ever since (thanks Debbie! thanks Prague! thanks team!).
Getting it into the Mac App Store is a big deal. We first added support to produce native app bundles earlier this year, such that any JavaFX application can be co-bundled with the JRE to create a platform specific app bundle — a MacOS X .app and .dmg, for example, or an .msi and .exe for windows, or .deb / .rpm on linux. These app bundles are inherently secure (since they don’t rely on remote code execution, unlike Applets and WebStart). They also are completely “normal” for the end user. And they’re the only way to get apps into an App store. Oh, and since Java is co-bundled, these app bundles do not require Java to be preinstalled — so no more headaches dealing with what version of Java is installed and redirecting to install a specific version of Java. It all just works.
So go ahead. Build your desktop applications with JavaFX, and deploy to the Mac app store. You’ll be glad you did 😉
by Richard Bair | Sep 4, 2012 | News
We’ve been working hard on performance lately for FX 8. Following is a performance report from Katya Pavlova, one of the members of our performance team who gives us regular (at least weekly) updates on the performance of the platform.
Notable Improvements (comparing to fx2.2-b21-ga)
There are a lot of improvements integrated into fx8.0. Most significant are:
- Multithreading has been implemented and turned on
- RT-15195 “Allow QuantumRenderer thread and FX Application thread to run in parallel”
- A lot of Controls improvements including:
- RT-23873 “Investigate (and improve) ListView / TreeView / TableView performance”
- RT-20840 “fx2.2-h17-b01: Adding new column to TableView results in creating new N columns instead of 1”
- RT-22244 “Pisces Renderer shows huge performance win when coded in C”
- Web node improvements
JavaFX 8.0 performance was improved for almost all benchmarks. In particular performance was improved for:
- more than 50% in Charts
- more than 100% in some Controls
- up to 30% in DirtyArea
- more than 20% in FXFire
- up to 30% in Guimark2.Bitmap and Guimark2.Vector
- up to 30% in JFXPanel-GUIMark2.Bitmap and more than 100% in JFXPanel-GUIMark2.Vector
- more than 30% in Layout
- up to 20% in WebNode.Guimark2-Text
