Ah, I see. > I would probably just treat anything thats > 1.0 as HiDPI.
Good call, at least for the purposes of selecting icons/bitmap graphics. (In my case I have an app that generates some graphics which it tries to align to pixel boundaries. So in retina mode it aligns to "half-pixels" instead of pixels. I'll have to see if it's worth trying to align to pixels on more general scale factors, or whether I should just not try to do any alignment at all on the odd HiDPI modes...) -- Eirik On 12/1/13, 8:54 AM, "Robert Krüger" <krue...@lesspain.de> wrote: >Yes, that's what I mean. On my Macbook Pro I can choose out of five >settings if I choose "scaled" rather than "best for retina display" >and I, for example, use the "more space" setting to have a maximum >resolution in terms of pixels and I doubt this is 2.0, so your check >would probably fail although it would make sense to use the >higher-resolution graphics on my Macbook with that setting. I would >probably just treat anything thats > 1.0 as HiDPI. > >Robert > >On Sat, Nov 30, 2013 at 8:09 PM, Eirik Bakke <eba...@mit.edu> wrote: >> Quite possible--do you mean if the scale factor is not exactly 1.0 or >>2.0? >> In that case, yes, you should need to get the actual scale factor from >>the >> AffineTransform. But I'm unsure how often scale factors other than 1.0 >>or >> 2.0 are encountered (surely there can't be more than two sets of icons >>for >> every app... unless everyone provides bitmap for the low resolution and >> SVG for the higher ones). >> >> I should add that I have only tested the Retina mode using the "Enable >> HiDPI display modes" option from the Graphics Tools for XCode [1]. And >> that one only lets me try 2x scale factors. >> >> -- Eirik >> >> [1] >> >>http://stackoverflow.com/questions/12124576/how-to-simulate-a-retina-disp >>la >> y-hidpi-mode-in-mac-os-x-10-8-mountain-lion-on >> >> -- Eirik >> >> On 11/30/13, 7:04 AM, "Robert Krüger" <krue...@lesspain.de> wrote: >> >>>Don't the scale factors depend on the individual user's retina >>>settings? Of course, your approach will also work if that is the case, >>>it will just require some more checks. >>> >>>On Fri, Nov 29, 2013 at 11:26 PM, Eirik Bakke <eba...@mit.edu> wrote: >>>> This did the trick for me: >>>> >>>> // g is the Graphics2D object fed to the paint() or paintComponent() >>>> method of your Swing component. >>>> >>>>g.getFontRenderContext().getTransform().equals(AffineTransform.getScale >>>>In >>>>st >>>> ance(2.0, 2.0)) >>>> >>>> >>>> It uses no private APIs, and has the advantage that it lets you make >>>>the >>>> retina-or-not decision on a component-to-component basis (or in >>>>practice, >>>> on a window-to-window basis, as all components in the same window have >>>>the >>>> same FontRenderContext). This means if your user has one window on >>>>their >>>> retina laptop screen and another on their non-retina external monitor, >>>> both will render appropriately for their respective devices (I've >>>> confirmed this to work on Java 1.7.0_45 for MacOS X 10.8.5). >>>> >>>> -- Eirik >>>> >>>> On 11/29/13, 7:36 AM, "Hendrik Schreiber" <h...@tagtraum.com> wrote: >>>> >>>>>Hey.. >>>>> >>>>>with some of the Retina work appearing in 1.7.0_60, what is the >>>>>recommended way for the developer to find out, whether images are/can >>>>>be >>>>>scaled, i.e., whether we are dealing with a HiDPI display. >>>>> >>>>>In the past, on the Apple JVM, we used: >>>>> >>>>> final Float scaleFactor = (Float) >>>>>Toolkit.getDefaultToolkit().getDesktopProperty("apple.awt.contentScale >>>>>Fa >>>>>ct >>>>>or"); >>>>> >>>>>Is there an equivalent? >>>>> >>>>>I very much appreciate that you are pushing some of the work down to >>>>>1.7.0_60. Can you say what parts should now/soon work and how to use >>>>>them? >>>>> >>>>>Thank you, >>>>> >>>>>-hendrik >>>> >>
