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 <[email protected]>
Java Embedded Development
"Experience is a hard teacher because she gives the test first, the lesson
afterwards."
-- Vernon Sanders Law
