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.
