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 

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.h...@oracle.com>
Java Embedded Development

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

Reply via email to