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.pet...@oracle.com> 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. >>