JDK-8102594 : Mac: Glass Robot API must be able to take HiDPI (retina) screenshots
  • Type: Enhancement
  • Component: javafx
  • Sub-Component: window-toolkit
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-02-08
  • Updated: 2015-06-16
  • Resolved: 2013-03-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Fixed
Related Reports
Relates :  
JDK-8119517 - Mac: GlassRobot gets a wrong screenshot for Mac OS X (LoDPI, HiDPI)
Description
Now there are no special Robot API & there is not a parameter at the getScreenCapture(...)  method to determine screenshot mode (HiDPI / LoDPI)
Comments
Introduced a new method: /** * Returns a capture of the specified rectangular area of the screen. * * If {@code isHiDPI} argument is {@code true}, the returned Pixels object * dimensions may differ from the requested {@code width} and {@code * height} depending on how many physical pixels the area occupies on the * screen. E.g. in HiDPI mode on the Mac (aka Retina display) the pixels * are doubled, and thus a screen capture of an area of size (10x10) pixels * will result in a Pixels object with dimensions (20x20). Calling code * should use the returned objects's getWidth() and getHeight() methods * to determine the image size. * * If (@code isHiDPI) is {@code false}, the returned Pixels object is of * the requested size. Note that in this case the image may be scaled in * order to fit to the requested dimensions if running on a HiDPI display. */ Pixels Robot.getScreenCapture(int x, int y, int width, int height, boolean isHiDPI);
07-03-2013
Upgrading this to blocker as this issue prevents us from automated Hi-DPI testing
12-02-2013
There are several issues with this workaround: - we do not know how to do that. Can you give us some hints? - is it guaranteed that the in-memory image will be the same as seen on the display? Why can we rely on it?
12-02-2013
A workaround for testing HiDPI rendering for Lombard is to draw to in-memory images and examine them rather than taking live screenshots.
11-02-2013