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.

Reply via email to