Hi David,
sorry to keep you waiting with an answer from Embedded SQE.
I assume there will be no major impact on SQE since as you told and it
is true, most golden image tests we have are based on a window content.
Anyway from what I understood your implementation will be easily rolled
back if we reveal some unexpected impact on tests, right?
26.03.2014 23:03, 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.
--
Best regards,
Stas Smirnov
Stas Smirnov | Java Embedded
Phone: +7 812 3346130 | Mobile: +7 921 9262241
Oracle Development SPB, LLC
10th Krasnoarmeyskaya 22A, St. Petersburg, 190103, Russia
