Re: Glass Robot and getSCreenCapture

2014-03-26 Thread Jack Moxley 
It should be throwing an exception or returning null, returning a real value is 
a code smell.

Sent from my iPhone

 On 23 Mar 2014, at 07:55, Daniel Blaukopf daniel.blauk...@oracle.com wrote:
 
 We should be consistent about what we return, although I agree that that the 
 actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable.
 
 On Mar 21, 2014, at 7:05 PM, Anthony Petrov anthony.pet...@oracle.com 
 wrote:
 
 Hi David,
 
 I don't think we're making any assumptions. We feed the coordinates to a 
 native API and rely on the OS to do the right thing.
 
 In other words, our assumption is that if the box lays (partially or fully) 
 outside of the screen area, then the behavior is undefined. Note that the 
 Screen API in Glass allows its clients to check what coordinates are valid 
 (i.e. belong to a real screen).
 
 So whatever your return for pixels outside of screen bounds should be fine. 
 0x0 or 0xff00 - both look good. However, I agree that a stricter 
 specification and a check might be the best solution.
 
 --
 best regards,
 Anthony
 
 On 3/21/2014 8:53 PM, David Hill wrote:
 
 I have been working on a problem with Robot.getScreenCapture() on a 565
 ARM device, and while doing so, encountered a couple of questions which
 I will bring up:
 
 Pixxls getScreenCapture(int x, int y, int width, int height, boolean
 isHiDPI)
 
 I don't seem any real documentation that says how x,y + width,height
 should be treated when compared to the reality of the Screen.
 What values of x,y + width,height  are reasonable ? I can picture any
 number of scenarios with them that would result in a box that does not
 fit within the Screen dimensions. The only implementing code I have seen
 checks to that the width  height are = 1. Can I/Should I handle -x
 values ? What if the requested bounds exceed the screen ?
 
 If we are making assumptions that the requested box is inside the
 screen then why don't we document that fact and add a check in the
 Robot class (instead of relying on the native impls).
 
 If we are assuming the requested box does not have to lie within the
 screen bounds - what should the returned values be for the pixels
 outside the screen ? Pixel Black ? (Currently I think Lens would return
 0x instead of 0xff00)
 
 My recommendation would be modify the JavaDoc contract to specify that
 the x,y and x+width, y+height must be within the screen bounds, with an
 IllegalArgumentException if out of bounds. This would be checked in
 Robot, prior to calling the native impls.
 
 This code is internal API, so I expect the real impact would be on SQE.

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread Stephen F Northover 

Hi David,

Sorry to be getting to this so late.  An uninitialized pixel is normally 
considered to be black.  If you throw an exception, clients will need to 
either catch the exception or perform the same test that you are 
performing before they call the API.  Since this is not pubic API, no 
client will be affected so even if we make the change to throw the 
exception and then decide not to do this later, we can change it.


What is happening now?  Who is being affected by this bug?  Is it easy 
to change the implementations to return black?  This seems better to me 
than throwing the exception.


As I say, if we throw the exception, then we will only break ourselves, 
not clients of FX API.  Have we ensured that the exception will not 
break SQE tests.


Again, sorry to be getting to this so late and apologies if all of this 
has been discussed in another thread that I missed,

Steve

On 2014-03-25 2:46 PM, David Hill wrote:

On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:

Having heard a little feedback, here is my proposal in the form of a 
review request :-)



My recommendation would be modify the JavaDoc contract to specify 
that the x,y and x+width, y+height must be within the screen bounds, 
with an IllegalArgumentException if out of bounds. This would be 
checked in Robot, prior to calling the native impls.


This code is internal API, so I expect the real impact would be on 
SQE.
I really like the idea of adding a bounds restriction - so that the 
requested bounds must be within the Screen.
It seems the simplest solution to my issue of handling the odd edge 
case of out of bound pixels, with the least likely impact.


This means that existing code in the implementations are not affected.
I suspect that there will we little if any impact on SQE tests, given 
that most of us would avoid asking for a screen capture with undefined 
pixels. I do expect that we will encounter a few exceptions to this 
when tests are run on smaller displays (like embedded).


I also added bounds checking to Robot.getPixelColor() for consistency, 
and because Embedded passes this call through to common code for 
screen capture.


I did a grep through the JavaFX code base, and don't see any JavaFX 
use cases. I expect any golden image test code could be affected.


I separated out this internal API changes from my embedded changes so 
we have a clear and easy thing to review.


Jira: https://javafx-jira.kenai.com/browse/RT-36382

Patch: is inline in the Jira, but also here:

diff -r bb72bd2fa889 
modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
--- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue 
Mar 25 14:21:26 2014 -0400
+++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue 
Mar 25 14:41:37 2014 -0400

@@ -144,9 +144,20 @@
 protected abstract int _getPixelColor(int x, int y);
 /**
  * Returns pixel color at specified screen coordinates in IntARGB 
format.

+ *
+ * If the requested pixel is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
  */
 public int getPixelColor(int x, int y) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x = s.getWidth() || y  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getPixelColor(x, y);
 }

@@ -162,13 +173,27 @@
  * will result in a Pixels object with dimensions (20x20). 
Calling code
  * should use the returned objects's getWidth() and getHeight() 
methods

  * to determine the image size.
- *
+ *
  * If (@code isHiDPI) is {@code false}, the returned Pixels 
object is of
  * the requested size. Note that in this case the image may be 
scaled in
  * order to fit to the requested dimensions if running on a HiDPI 
display.

+ *
+ * If the requested capture bounds is not contained by the actual 
Screen

+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
+ * @param width The of width the requested capture (must be =1 
and fit on the screen)
+ * @param height The of width the requested capture (must be =1 
and fit on the screen)

+ * @param isHiDPI return HiDPI if available
  */
 public Pixels getScreenCapture(int x, int y, int width, int 
height, boolean isHiDPI) {

 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x + width  s.getWidth() || y + height  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getScreenCapture(x, y, width,

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread Scott Palmer 
It isn't public API now.. but keep in mind that making it public in
some way has been requested for over two years.  See RT-17571
Since those issues have made the internal Robot API known, no doubt
people are using it. (We all know how well people listen to the
warnings about using internal APIs .. *cough* sun.misc.Unsafe *cough*)

Cheers,

Scott

On Wed, Mar 26, 2014 at 10:59 AM, Stephen F Northover
steve.x.northo...@oracle.com wrote:
 Hi David,

 Sorry to be getting to this so late.  An uninitialized pixel is normally
 considered to be black.  If you throw an exception, clients will need to
 either catch the exception or perform the same test that you are performing
 before they call the API.  Since this is not pubic API, no client will be
 affected so even if we make the change to throw the exception and then
 decide not to do this later, we can change it.

 What is happening now?  Who is being affected by this bug?  Is it easy to
 change the implementations to return black?  This seems better to me than
 throwing the exception.

 As I say, if we throw the exception, then we will only break ourselves, not
 clients of FX API.  Have we ensured that the exception will not break SQE
 tests.

 Again, sorry to be getting to this so late and apologies if all of this has
 been discussed in another thread that I missed,
 Steve


 On 2014-03-25 2:46 PM, David Hill wrote:

 On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:

 Having heard a little feedback, here is my proposal in the form of a
 review request :-)



 My recommendation would be modify the JavaDoc contract to specify that
 the x,y and x+width, y+height must be within the screen bounds, with an
 IllegalArgumentException if out of bounds. This would be checked in Robot,
 prior to calling the native impls.

 This code is internal API, so I expect the real impact would be on SQE.

 I really like the idea of adding a bounds restriction - so that the
 requested bounds must be within the Screen.
 It seems the simplest solution to my issue of handling the odd edge case
 of out of bound pixels, with the least likely impact.

 This means that existing code in the implementations are not affected.
 I suspect that there will we little if any impact on SQE tests, given that
 most of us would avoid asking for a screen capture with undefined pixels. I
 do expect that we will encounter a few exceptions to this when tests are run
 on smaller displays (like embedded).

 I also added bounds checking to Robot.getPixelColor() for consistency, and
 because Embedded passes this call through to common code for screen capture.

 I did a grep through the JavaFX code base, and don't see any JavaFX use
 cases. I expect any golden image test code could be affected.

 I separated out this internal API changes from my embedded changes so we
 have a clear and easy thing to review.

 Jira: https://javafx-jira.kenai.com/browse/RT-36382

 Patch: is inline in the Jira, but also here:

 diff -r bb72bd2fa889
 modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
 --- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar
 25 14:21:26 2014 -0400
 +++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar
 25 14:41:37 2014 -0400
 @@ -144,9 +144,20 @@
  protected abstract int _getPixelColor(int x, int y);
  /**
   * Returns pixel color at specified screen coordinates in IntARGB
 format.
 + *
 + * If the requested pixel is not contained by the actual Screen
 + * bounds an IllegalArgumentException will be thrown.
 + *
 + * @param x The screen X of the requested capture (must be =0)
 + * @param y The screen Y of the requested capture (must be =0)
   */
  public int getPixelColor(int x, int y) {
  Application.checkEventThread();
 +Screen s = Screen.getMainScreen();
 +if (x  0 || y  0 ||
 +x = s.getWidth() || y  s.getHeight()) {
 +   throw new IllegalArgumentException(Capture out of bounds);
 +}
  return _getPixelColor(x, y);
  }

 @@ -162,13 +173,27 @@
   * will result in a Pixels object with dimensions (20x20). Calling
 code
   * should use the returned objects's getWidth() and getHeight()
 methods
   * to determine the image size.
 - *
 + *
   * If (@code isHiDPI) is {@code false}, the returned Pixels object is
 of
   * the requested size. Note that in this case the image may be scaled
 in
   * order to fit to the requested dimensions if running on a HiDPI
 display.
 + *
 + * If the requested capture bounds is not contained by the actual
 Screen
 + * bounds an IllegalArgumentException will be thrown.
 + *
 + * @param x The screen X of the requested capture (must be =0)
 + * @param y The screen Y of the requested capture (must be =0)
 + * @param width The of width the requested capture (must be =1 and
 fit on the screen)
 + * @param height The of width the requested capture (must be =1 and

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread David Hill 

On 3/26/14, Mar 26, 10:59 AM, Stephen F Northover wrote:

Hi David,

Sorry to be getting to this so late.  An uninitialized pixel is normally considered to be 
black.  If you throw an exception, clients will need to either catch the exception or 
perform the same test that you are performing before they call the API. Since 
this is not pubic API, no client will be affected so even if we make the change to throw 
the exception and then decide not to do this later, we can change it.

What is happening now?  Who is being affected by this bug?  Is it easy to 
change the implementations to return black?  This seems better to me than 
throwing the exception.


Why ? Because I happened to have to fix some code and saw that what we had in 
ARM was broken, or at least made some poor assumptions around out of bounds 
pixels.

I really, really don't like implied contract code, and robot screen capture 
is certainly implied. My preference in javadoc, even on internal API that outlines the 
expected behavior, instead of having to read impl code on platforms I am not familiar 
with.

The main item still is:
  * what does an out of bounds pixel look like. The current answer is - 
depends. Certainly on ARM some of the existing code would return one of, 
uninitialized, or 0. Note that 0 is not always the same as black (0xff00).

I sought to make the impl code easier by denying a call that would be out of 
bounds. I am finding that this may be difficult or even impossible, when you 
glue two screens of different sizes. Thanks to Anthony educating me on how this 
works.

I did glance through the other impls code and I did not see any specific 
handling of out of bounds pixels. Anthony says that handling was done by the 
the underlying system calls.


As I say, if we throw the exception, then we will only break ourselves, not 
clients of FX API.  Have we ensured that the exception will not break SQE tests.

Ensured ? Not sure that is possible except by running the SQE tests with a 
restriction in place. I have asked for a reading from SQE but have not heard 
back yet.
But this discussion should be happening anyway, as we discuss what should or 
should not be done.

Dave


Again, sorry to be getting to this so late and apologies if all of this has 
been discussed in another thread that I missed,
Steve

On 2014-03-25 2:46 PM, David Hill wrote:

On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:

Having heard a little feedback, here is my proposal in the form of a review 
request :-)



My recommendation would be modify the JavaDoc contract to specify that the x,y 
and x+width, y+height must be within the screen bounds, with an 
IllegalArgumentException if out of bounds. This would be checked in Robot, 
prior to calling the native impls.

This code is internal API, so I expect the real impact would be on SQE.

I really like the idea of adding a bounds restriction - so that the requested 
bounds must be within the Screen.
It seems the simplest solution to my issue of handling the odd edge case of out 
of bound pixels, with the least likely impact.

This means that existing code in the implementations are not affected.
I suspect that there will we little if any impact on SQE tests, given that most 
of us would avoid asking for a screen capture with undefined pixels. I do 
expect that we will encounter a few exceptions to this when tests are run on 
smaller displays (like embedded).

I also added bounds checking to Robot.getPixelColor() for consistency, and 
because Embedded passes this call through to common code for screen capture.

I did a grep through the JavaFX code base, and don't see any JavaFX use cases. I expect 
any golden image test code could be affected.

I separated out this internal API changes from my embedded changes so we have a 
clear and easy thing to review.

Jira: https://javafx-jira.kenai.com/browse/RT-36382

Patch: is inline in the Jira, but also here:

diff -r bb72bd2fa889 modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
--- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 
14:21:26 2014 -0400
+++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 
14:41:37 2014 -0400
@@ -144,9 +144,20 @@
 protected abstract int _getPixelColor(int x, int y);
 /**
  * Returns pixel color at specified screen coordinates in IntARGB format.
+ *
+ * If the requested pixel is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
  */
 public int getPixelColor(int x, int y) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x = s.getWidth() || y  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getPixelColor(x, y);
 }

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread 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.

--
David Hill david.h...@oracle.com
Java Embedded Development

Experience is a hard teacher because she gives the test first, the lesson 
afterwards.
-- Vernon Sanders Law

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread David DeHaven 

 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 :-(

When pressing Command+Shift+3, the Mac creates separate images for each display.

-DrD-

Re: Glass Robot and getSCreenCapture

2014-03-26 Thread 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

Re: Glass Robot and getSCreenCapture

2014-03-25 Thread David Hill 

On 3/21/14, Mar 21, 12:53 PM, David Hill wrote:

Having heard a little feedback, here is my proposal in the form of a review 
request :-)



My recommendation would be modify the JavaDoc contract to specify that the x,y 
and x+width, y+height must be within the screen bounds, with an 
IllegalArgumentException if out of bounds. This would be checked in Robot, 
prior to calling the native impls.

This code is internal API, so I expect the real impact would be on SQE.

I really like the idea of adding a bounds restriction - so that the requested 
bounds must be within the Screen.
It seems the simplest solution to my issue of handling the odd edge case of out 
of bound pixels, with the least likely impact.

This means that existing code in the implementations are not affected.
I suspect that there will we little if any impact on SQE tests, given that most 
of us would avoid asking for a screen capture with undefined pixels. I do 
expect that we will encounter a few exceptions to this when tests are run on 
smaller displays (like embedded).

I also added bounds checking to Robot.getPixelColor() for consistency, and 
because Embedded passes this call through to common code for screen capture.

I did a grep through the JavaFX code base, and don't see any JavaFX use cases. I expect 
any golden image test code could be affected.

I separated out this internal API changes from my embedded changes so we have a 
clear and easy thing to review.

Jira: https://javafx-jira.kenai.com/browse/RT-36382

Patch: is inline in the Jira, but also here:

diff -r bb72bd2fa889 modules/graphics/src/main/java/com/sun/glass/ui/Robot.java
--- a/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 
14:21:26 2014 -0400
+++ b/modules/graphics/src/main/java/com/sun/glass/ui/Robot.java Tue Mar 25 
14:41:37 2014 -0400
@@ -144,9 +144,20 @@
 protected abstract int _getPixelColor(int x, int y);
 /**
  * Returns pixel color at specified screen coordinates in IntARGB format.
+ *
+ * If the requested pixel is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
  */
 public int getPixelColor(int x, int y) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x = s.getWidth() || y  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getPixelColor(x, y);
 }

@@ -162,13 +173,27 @@
  * will result in a Pixels object with dimensions (20x20). Calling code
  * should use the returned objects's getWidth() and getHeight() methods
  * to determine the image size.
- *
+ *
  * If (@code isHiDPI) is {@code false}, the returned Pixels object is of
  * the requested size. Note that in this case the image may be scaled in
  * order to fit to the requested dimensions if running on a HiDPI display.
+ *
+ * If the requested capture bounds is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
+ * @param width The of width the requested capture (must be =1 and fit on 
the screen)
+ * @param height The of width the requested capture (must be =1 and fit 
on the screen)
+ * @param isHiDPI return HiDPI if available
  */
 public Pixels getScreenCapture(int x, int y, int width, int height, 
boolean isHiDPI) {
 Application.checkEventThread();
+Screen s = Screen.getMainScreen();
+if (x  0 || y  0 ||
+x + width  s.getWidth() || y + height  s.getHeight()) {
+   throw new IllegalArgumentException(Capture out of bounds);
+}
 return _getScreenCapture(x, y, width, height, isHiDPI);
 }

@@ -176,6 +201,14 @@
  * Returns a capture of the specified area of the screen.
  * It is equivalent to calling getScreenCapture(x, y, width, height, 
false),
  * i.e. this method takes a LowDPI screen shot.
+ *
+ * If the requested capture bounds is not contained by the actual Screen
+ * bounds an IllegalArgumentException will be thrown.
+ *
+ * @param x The screen X of the requested capture (must be =0)
+ * @param y The screen Y of the requested capture (must be =0)
+ * @param width The of width the requested capture (must be =1 and fit on 
the screen)
+ * @param height The of width the requested capture (must be =1 and fit 
on the screen)
  */
 public Pixels getScreenCapture(int x, int y, int width, int height) {
 return getScreenCapture(x, y, width, height, false);


--
David Hill david.h...@oracle.com
Java Embedded Development

On a clear disk, you can seek

Re: Glass Robot and getSCreenCapture

2014-03-23 Thread Daniel Blaukopf 
We should be consistent about what we return, although I agree that that the 
actual value doesn’t seem to matter. 0 for imaginary pixels seems reasonable.

On Mar 21, 2014, at 7:05 PM, Anthony Petrov anthony.pet...@oracle.com wrote:

 Hi David,
 
 I don't think we're making any assumptions. We feed the coordinates to a 
 native API and rely on the OS to do the right thing.
 
 In other words, our assumption is that if the box lays (partially or fully) 
 outside of the screen area, then the behavior is undefined. Note that the 
 Screen API in Glass allows its clients to check what coordinates are valid 
 (i.e. belong to a real screen).
 
 So whatever your return for pixels outside of screen bounds should be fine. 
 0x0 or 0xff00 - both look good. However, I agree that a stricter 
 specification and a check might be the best solution.
 
 --
 best regards,
 Anthony
 
 On 3/21/2014 8:53 PM, David Hill wrote:
 
 I have been working on a problem with Robot.getScreenCapture() on a 565
 ARM device, and while doing so, encountered a couple of questions which
 I will bring up:
 
 Pixxls getScreenCapture(int x, int y, int width, int height, boolean
 isHiDPI)
 
 I don't seem any real documentation that says how x,y + width,height
 should be treated when compared to the reality of the Screen.
 What values of x,y + width,height  are reasonable ? I can picture any
 number of scenarios with them that would result in a box that does not
 fit within the Screen dimensions. The only implementing code I have seen
 checks to that the width  height are = 1. Can I/Should I handle -x
 values ? What if the requested bounds exceed the screen ?
 
 If we are making assumptions that the requested box is inside the
 screen then why don't we document that fact and add a check in the
 Robot class (instead of relying on the native impls).
 
 If we are assuming the requested box does not have to lie within the
 screen bounds - what should the returned values be for the pixels
 outside the screen ? Pixel Black ? (Currently I think Lens would return
 0x instead of 0xff00)
 
 My recommendation would be modify the JavaDoc contract to specify that
 the x,y and x+width, y+height must be within the screen bounds, with an
 IllegalArgumentException if out of bounds. This would be checked in
 Robot, prior to calling the native impls.
 
 This code is internal API, so I expect the real impact would be on SQE.

Re: Glass Robot and getSCreenCapture

2014-03-21 Thread Anthony Petrov 

Hi David,

I don't think we're making any assumptions. We feed the coordinates to a 
native API and rely on the OS to do the right thing.


In other words, our assumption is that if the box lays (partially or 
fully) outside of the screen area, then the behavior is undefined. Note 
that the Screen API in Glass allows its clients to check what 
coordinates are valid (i.e. belong to a real screen).


So whatever your return for pixels outside of screen bounds should be 
fine. 0x0 or 0xff00 - both look good. However, I agree that a 
stricter specification and a check might be the best solution.


--
best regards,
Anthony

On 3/21/2014 8:53 PM, David Hill wrote:


I have been working on a problem with Robot.getScreenCapture() on a 565
ARM device, and while doing so, encountered a couple of questions which
I will bring up:

Pixxls getScreenCapture(int x, int y, int width, int height, boolean
isHiDPI)

I don't seem any real documentation that says how x,y + width,height
should be treated when compared to the reality of the Screen.
What values of x,y + width,height  are reasonable ? I can picture any
number of scenarios with them that would result in a box that does not
fit within the Screen dimensions. The only implementing code I have seen
checks to that the width  height are = 1. Can I/Should I handle -x
values ? What if the requested bounds exceed the screen ?

If we are making assumptions that the requested box is inside the
screen then why don't we document that fact and add a check in the
Robot class (instead of relying on the native impls).

If we are assuming the requested box does not have to lie within the
screen bounds - what should the returned values be for the pixels
outside the screen ? Pixel Black ? (Currently I think Lens would return
0x instead of 0xff00)

My recommendation would be modify the JavaDoc contract to specify that
the x,y and x+width, y+height must be within the screen bounds, with an
IllegalArgumentException if out of bounds. This would be checked in
Robot, prior to calling the native impls.

This code is internal API, so I expect the real impact would be on SQE.