Glass Robot and getSCreenCapture

[Stas Smirnov]

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