RFR: 8274939: Incorrect size of the pixel storage is used by the robot on macOS

[Sergey Bylokhov]

On Wed, 26 Jan 2022 21:38:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I wonder if a similar problem exist on Windows and Linux. The pixelArray is allocated as new int[bounds.width*bounds.height] in both. And for macOS too: CRobot.getRGBPixels allocates the array of size bounds.width*bounds.height, shouldn't it be twice as large if uiScale=2.0 is in effect?

On Linux and Windows we pass the size of the area to the system in the device space, so we store an image of the size we just allocated. The macOS is different we pass the coordinates in the users space -> when we pass 1x1 we may get 4x4 on the HiDPI screen, this is what the current fix changed.

>Why doesn't this need updating too ? Seems like it must be OK else we'd have massive over-runs ..

We do not need to change other getRGBPixels() method because its coordinates already converted to the pixels(device space), we do this in the shared code. Note that the method which changed by this fix however use the "1" as a width and height in the users space - this is a bug.

>Looking at what happens in native it seems like it should be possible to add a check that the
Java array has enough capacity to satisfy what the call to retrieve pixels expects.
I think it would be reasonable to throw InternalError if it does not !

The logic we use is this:
 1 We prepared the pixel storage using device space coordinates
 2 We capture the 1x1 unit in the users space, usually this is 1x1 pixel on lowdpi and 4x4 on hidpi screen, actually macOS may return any size
 3 If the macOS return some other size we down/up [scale](https://github.com/openjdk/jdk/blob/cab590517bf705418c7376edd5d7066b13b6dde8/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L352) it to the size we calculated at step 1

-------------

PR: https://git.openjdk.java.net/jdk/pull/5864