Glass Robot and getSCreenCapture

Jack Moxley jack at
Wed Mar 26 07:19:11 UTC 2014

It should be throwing an exception or returning null, returning a real value is a code smell.

Sent from my iPhone

> On 23 Mar 2014, at 07:55, Daniel Blaukopf <daniel.blaukopf at> wrote:
> We should be consistent about what we return, although I agree that that the actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable.
>> On Mar 21, 2014, at 7:05 PM, Anthony Petrov <anthony.petrov at> wrote:
>> Hi David,
>> I don't think we're making any assumptions. We feed the coordinates to a native API and rely on the OS to do the right thing.
>> In other words, our assumption is that if the box lays (partially or fully) outside of the screen area, then the behavior is undefined. Note that the Screen API in Glass allows its clients to check what coordinates are valid (i.e. belong to a real screen).
>> So whatever your return for pixels outside of screen bounds should be fine. 0x0 or 0xff000000 - both look good. However, I agree that a stricter specification and a check might be the best solution.
>> --
>> best regards,
>> Anthony
>>> On 3/21/2014 8:53 PM, David Hill wrote:
>>> I have been working on a problem with Robot.getScreenCapture() on a 565
>>> ARM device, and while doing so, encountered a couple of questions which
>>> I will bring up:
>>> Pixxls getScreenCapture(int x, int y, int width, int height, boolean
>>> isHiDPI)
>>> I don't seem any real documentation that says how x,y + width,height
>>> should be treated when compared to the reality of the Screen.
>>> What values of x,y + width,height  are reasonable ? I can picture any
>>> number of scenarios with them that would result in a box that does not
>>> fit within the Screen dimensions. The only implementing code I have seen
>>> checks to that the width & height are >= 1. Can I/Should I handle -x
>>> values ? What if the requested bounds exceed the screen ?
>>> If we are making assumptions that the requested box is inside the
>>> screen.... then why don't we document that fact and add a check in the
>>> Robot class (instead of relying on the native impls).
>>> If we are assuming the requested box does not have to lie within the
>>> screen bounds - what should the returned values be for the pixels
>>> outside the screen ? Pixel Black ? (Currently I think Lens would return
>>> 0x instead of 0xff000000)
>>> My recommendation would be modify the JavaDoc contract to specify that
>>> the x,y and x+width, y+height must be within the screen bounds, with an
>>> IllegalArgumentException if out of bounds. This would be checked in
>>> Robot, prior to calling the native impls.
>>> This code is "internal" API, so I expect the real impact would be on SQE.

More information about the openjfx-dev mailing list