The current behavior, of assuming the transform represents a transformation to physical pixels, makes some sense to me, since the transform is used to decide how fonts are rendered on a low level (e.g. whether to use hints or not). When implementing java.awt.print.Printable, the transform in the FontRenderContext will reflect the DPI used by the printer--could be 150 DPI, 300 DPI, etc. When printing to a PDF printer on windows, it corresponds to a DPI of 1200. So the FontRenderContext transform already has a well-defined meaning of mapping to _device_ pixels.
My own Swing app actually uses the value of the transform to detect HiDPI mode in a platform-independent way. The nice thing about it is that it works even if one window is on a HiDPI-enabled screen and another is not--if you drag the window from one monitor to another, the Swing component gets properly redrawn in the right mode. And it doesn't actually assume anything about "Retina" displays--any scaling works. But maybe the current behavior is inconsistent and needs to be split out into a different API. Such an API probably needs to be available per DisplayMode [1] rather than per GraphicsDevice [2] or Toolkit [3], and it needs to allow scalings other than 2x. Either way, the Javadoc for FontRenderContext should be updated to state clearly which design choice is made wrt. high-resolution displays. -- Eirik [1] http://docs.oracle.com/javase/7/docs/api/java/awt/DisplayMode.html [2] http://docs.oracle.com/javase/7/docs/api/java/awt/GraphicsDevice.html [3] http://docs.oracle.com/javase/7/docs/api/java/awt/Toolkit.html On 11/6/14, 1:01 PM, "Alan Snyder" <[email protected]> wrote: >I¹m curious about the behavior of FontRenderContext.getTransform() in >HiDPI mode. The documentation says it maps points to pixels, but it >doesn¹t say what kind of pixels. I would have assumed virtual pixels (AWT >pixels) for consistency with the rest of the API, but in fact I get a 2x >mapping on a simulated Retina display. Is this a good thing or a bug? > >Some API to reveal the HiDPI scaling factor is needed, but I would think >it should be a new API to avoid confusing old programs that don¹t know >about HiDPI mode. > >The larger issue - is there a plan to document HiDPI mode? I have not >found any mention of it in the docs other than a cryptic message that >Retina displays now work properly. All I have learned comes from mailing >lists, blogs, and reading source code. Some programs need to be updated >to work well in HiDPI mode, and documentation is needed on how to do that. > > Alan >
