Glass Robot and getSCreenCapture

[David Hill]

On 3/26/14, Mar 26, 12:53 PM, Stephen F Northover wrote:
> I don't like "implied" contract code either but I also don't like exceptions for cases like this.  I would prefer that we return zero for pixels that are unspecified as this seems better than testing screen bounds (which can get you in trouble on multi-display monitors).  Anyway, to fix this involves writing a test case that we can run on all platforms in a multi-monitor scenario.  Also, the primary monitor can be on either the left or the right and this might affect the result.
>
> It's easier to fix this in Java code by testing screen bounds as you were doing and throw the exception.  Since this is not API and we need to move on, then we could do this (and possibly break SQE). Alternately, we can construct the test cases, see if the platforms/glass already return zero and assess where to go next.
>
> Whatever happens, we need a test case.  Is there one in the JIRA? If so, I can run it on the desktop platforms and let you know the results for the current code base.
>
As much as I don't like it - I am no longer sure there is a reasonable pre-test that can be done. I suggested a four corner test, but in the case of two adjacent screens of different heights, it is reasonable to see that you could ask for bounds that would put 3 corners in, and one out (hopefully the asci art will work):

+------------+------------+
|            |            |
|            |            |
|            |            |
+------------+            |
              |            |
              +------------+

For a one shot screen capture - we would pass in top left and width and height to make the bottom right.
Currently this should work on Mac I am told, though what is in the out of bounds pixels is not known.
And if we added a third "tall" screen to the left, life gets even more complicated :-(

I was hoping to simplify the native impl for ARM by making it impossible to have an out of bounds pixel. This thought was in line with other API - check for valid values before calling the impl. We still could, but in the above case, there would not be a way to get all the screen in one shot.

I really don't think we should be having a major impact on SQE, as I would think that most golden image tests will be based on checking "known" things - like the content of a window. But ... I have erred recently in the past on this subject... :-)

The test case I have been using is in HelloSanity. It is "well behaved". It is only one of 2 apps in our repo that perform any screen captures (an the other was used as the basis for HelloSanity). There are some uses of getPixel(x,y) which is a variation.

I found the problem in the ARM code by inspection, and have yet to write a reasonable test app that includes the aprox 6-8 variations of overlap (ie, full subset, off left, off right, completely missing up, .....) I certainly can throw together something that will try some of the variations to see if we fail on other platforms.

Given my current understanding of the problem though, I really don't see how a pre-verification of the bounds can be done.

-- 
David Hill <David.Hill at Oracle.com>
Java Embedded Development

"Experience is a hard teacher because she gives the test first, the lesson afterwards."
-- Vernon Sanders Law