Glass Robot and getSCreenCapture
Stas Smirnov
stanislav.smirnov at oracle.com
Thu Mar 27 04:51:07 UTC 2014
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
More information about the openjfx-dev
mailing list