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!
This is really great to hear. Since switching development from Apple’s Java 6 to Oracle’s Java 7 for Swing UIs, I can say the experience on a Retina MBP is really quite nasty.
I’m really pleased to hear there might be some movement on this!
Brilliant!
Perhaps it would be worthwhile to consider something more general/better than apple’s @2x solution though? Android has it rather well covered with its resources, for example for graphics you can provide a wider range of dpi (ppi) resources: ldpi, mdpi, hdpi, xhdpi and xxhdpi. It’s a bit more elaborate than that but that’s the basics.
Your link to the Engadget article has an extra double quote at the end that is impeding the Engadget site to show the correct page when clicking your link.
It should be only http://www.engadget.com/2012/06/11/apple-macbook-pro-retina/ to be reached.
This comment is not intended to be published, but it is my least effort way of alerting you about the flaw. 😉
Thanks – fixed – and of course your comment is going to be published – we appreciate all feedback (even when we’re in the wrong) 🙂
I share the concerns expressed by Mattias. Following Apples example here would just be a short-sighted kludge but I also don’t like the approach taken by Android. What I would like to see is a really resolution independent specification of the GUI. Resources like icons should ideally be specified as vector graphics or high resolution images. General images should be provided in high resolution too and be scaled down if necessary (not up) with a quality scaler and JavaFX should provider clever caching mechanisms to ensure sufficient runtime performance. With todays hardware this is doable and we should stop putting all the burdon of managing all these little icons and images in different resolutions on the programmer. At least we are planning a GUI framework for the next 1-2 decades here.
Just my thoughts
Michael
Michael, vector graphics is not a solution to that though, lots of information to be found about that. A complement perhaps. One simple fact is that a lower density icon usually needs to be designed a little bit differently, else details are lost etc.
Regarding the android example: If a resource is not available in a lower density then a higher density version is used and scaled down. So that works as per your request there already.
Do you have any pointers to why using vector graphics would not be a good idea besides the one you have mentioned? Of course I was not thinking about using just one definition of a complex graphic for all resolutions. What I have in mind is a graphic definition with something like a level-of-detail node which would determine what parts or which geometry to paint for different physical resolutions.
Been trying to post a reply to this now and then ever since your reply, doesn’t seem to get through. Trying again today.
I like this link regarding vector icons:
Maybe links are not allowed? Trying without a proper link, google for:
pushing pixels vector icons
Pushing pixels is a blog, and a blog entry from Nov 4 2011 talks about this.
Interesting, so without a link the reply got through, spam filter I guess.
Trying with underscores instead of periods in the domain name:
www_pushing-pixels_org/2011/11/04/about-those-vector-icons.html
Interesting reading, although I still think it is doable. Let’s see what the future will bring.
Any news here?
It’ll get fixed. But I wouldn’t be surprised if it took a month or two to get to there (open sourcing and other activities are at the front burner right now)
Fine! Will it be fixed in JavaFX only or in Swing too?
I’ve seen that the newest builds of JavaFX now has retina support. Which is awesome. But as Tobi asks, will Swing get this support too?
Thanks!
the retina support in b75 is really awesome and works fine! Do you plan to support hiDPI in Swing too?
Hi guys,
sorry to be a bother about this, but any kind of answer about what’s going to happen regarding Retina-support (or non-support which I really hope is not the case…) for Swing would be greatly appreciated.
Thanks
We’re adding retina support for Swing. Cheers 😉
Thank you for the answer Richard!
And an awesome answer as well!
I’ve been a Java developer for more than 10 years now and I just want to add that there is such a feeling of revival in the Java sphere all because of the work of the Oracle Java/JavaFx team for the last couple of years. THANK YOU ALL! 🙂
Yes, we need retina support in Swing too! We can’t port to Java7/8 without retina support 🙁
Is there already some kind of @2x support in JavaFX 8 (ea)? If not, how does one have to handle images in a JavaFX app on a Retina device?