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

Reply via email to