Glass Robot and getSCreenCapture

[Anthony Petrov]

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.
>