<AWT Dev> Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot
Alexandr Scherbatiy
alexandr.scherbatiy at oracle.com
Mon Feb 13 07:35:53 UTC 2017
The fix looks good to me.
Thanks,
Alexandr.
On 2/10/2017 9:24 AM, Prem Balakrishnan wrote:
>
> Hi Phil,
>
> Sorry, I misinterpreted the example code.
>
> Updated patch as suggested:
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.11/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.11/>
>
> I have raised CCC request for the same.
>
> Regards,
>
> Prem
>
> *From:*Phil Race
> *Sent:* Friday, February 10, 2017 1:54 AM
> *To:* Prem Balakrishnan; Alexander Scherbatiy
> *Cc:* Sergey Bylokhov; awt-dev at openjdk.java.net
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot
> artifacts using AWT Robot
>
> Your example here is not what I wrote :-
>
> 443 * Image nativeResImage;
> 444 * Image baseResImage;
> 445 * MultiResolutionImage mrImage =
> robot.createMultiResolutionScreenCapture(frame.getBounds());
> 446 * List<Image> resolutionVariants =
> mrImage.getResolutionVariants();
> 447 * if (resolutionVariants.size() > 1) {
> 448 * nativeResImage = resolutionVariants.get(1);
> 449 * } else {
> 450 * baseResImage = resolutionVariants.get(0);
> 451 * } </pre>
>
>
> The result of that example is that only one of
>
> nativeResImage or baseResImage is non-null and the developer then needs
> to check again.
> I defined only nativeResImage on purpose. If there is only one resolution
> variant then it must be the nativeResImage .. so the way I coded it was
> trying to show how you always get the unscaled result.
> So I recommend updating it as I originally suggested.
> Also please file the CCC today - the example part won't hold up that
> since it is not spec. significant.
> -phil.
>
> On 02/09/2017 01:49 AM, Prem Balakrishnan wrote:
>
> Hi Phil,
>
> Thank you for the review.
>
> Updated patch:
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.10/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.10/>
>
> Regards,
>
> Prem
>
> *From:*Phil Race
> *Sent:* Thursday, February 09, 2017 1:59 AM
> *To:* Prem Balakrishnan; Alexander Scherbatiy
> *Cc:* Sergey Bylokhov; awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot
> artifacts using AWT Robot
>
> Two minor grammar issues in the javadoc
>
> This method should be used in case where there is a scaling transform
>
> ->
>
> This method can be used in case there is a scaling transform
>
> * For a high resolution display where there is scaling transform,
>
> ->
>
> * For a high resolution display where there is a scaling transform,
>
>
> Also I think we should show as an example in the javadoc how you
> would use it to get the hi-res image if you want it.
> Derived fom Alexander's off-list email :
> Image nativeResImage;
> MultiResolutionImage mrImage =
> robot.createMultiResolutionScreenCapture(frame.getBounds());
> List<Image> resolutionVariants =
> mrImage.getResolutionVariants();
> if (resolutionVariants.size() > 1) {
> nativeResImage = resolutionVariants.get(1);
> } else {
> nativeResImage = resolutionVariants.get(0);
> }
>
> -phil.
>
> On 02/08/2017 12:48 AM, Prem Balakrishnan wrote:
>
> Thank you Alex for the review.
>
> Updated patch:
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.09/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.09/>
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Tuesday, February 07, 2017 10:54 PM
> *To:* Prem Balakrishnan; Philip Race
> *Cc:* Sergey Bylokhov; awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot
> artifacts using AWT Robot
>
> On 2/6/2017 1:19 PM, Prem Balakrishnan wrote:
>
>
>
> Hi Phil and Alex,
>
> Please review updated patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.08/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.08/>
>
>
> Just as a small optimization. The private method
> Robot.createCompatibleImage(...) can return an array of
> BufferedImage-s.
> The createScreenCapture(...) can return just an image from
> the zero index and the createMultiResolutionScreenCapture(...)
> returns BaseMultiResolutionImage(array of images).
>
> It is better if the public javadoc part is checked by a
> native speaker.
>
> Thanks,
> Alexandr.
>
>
>
> Multi-monitor scenario will be handled under JDK-8173972.
>
> https://bugs.openjdk.java.net/browse/JDK-8173972
>
> Regards,
>
> Prem
>
> *From:*Phil Race
> *Sent:* Tuesday, January 31, 2017 5:24 AM
> *To:* Prem Balakrishnan; Alexander Scherbatiy
> *Cc:* Sergey Bylokhov; awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI] screenshot
> artifacts using AWT Robot
>
> I like
>
> 3. createMultiresolutionScreenCapture(Rectangle rect);
>
>
>
>
>
> -phil.
>
>
>
>
> On 01/30/2017 01:11 AM, Prem Balakrishnan wrote:
>
> Hi Phil,
>
> Thank you for the review.
>
> >Is Robot only capable of a screen capture from the
> default screen ? I hope not.
>
> Robot.createScreenCapture() can be used to capture
> screenshots on Multi-Monitor as well.
>
> To capture screen on Multi-Monitor user should calculate
> the total width of multiple
>
> screens, based on the position of secondary monitor(i.e.,
> Right/Left) with respect to
>
> main monitor and pass it to createScreenCapture() method.
>
> >So I would expect that where there are two screens with
> different DPI settings/transforms
> >the logic in here will be sensitive to the target screen.
>
> I tried with MacBookPro (macOS Sierra version 10.12 ,
> Retina ) by connecting a secondary monitor non-Retina display.
>
> keeping secondary monitor to the right/left of main
> display and targeted rectangle on each sides, expected
> results are obtained.
>
> The current patch addresses most common scenario of single
> HiDPI monitor setup and dual monitor (Hi-DPI, non-HiDPI)
> setup.
>
> As “Handling multi monitor setup with different DPI
> settings” requires additional effort to make it work on
> all platforms, I propose to fix it separately.
>
> >And what happens if the target rectangle overlaps the
> edge between two screens ?
>
> I tried this scenario with Mac connecting non-retina
> secondary monitor, OS doesn’t allow user to place a
> window in between two screens.
>
> >The more significant API change is that the isHiDPI
> parameter is a misnomer.
> >It really means something else and I think what we should
> do is delete it
> >and change the method name to something else.
>
> Thank you for the Draft.
>
> From my point of view, I think we should maintain the
> method name “createScreenCapture()”, because two functions
> doing the same task
>
> should have the same name so that method will have
> maximum proximal visibility i.e., developer will easily
> know that there exists two method variants to take
> screenshots.
>
> (At least the method name should start with create….);
>
> Some of the signatures we can choose from:
> 1. createScreenCapture(int x, int y, int width, int height);
>
> 2. createScreenCapture(Point pt, Dimension d);
>
> 3. createMultiresolutionScreenCapture(Rectangle rect);
>
> 4. createMultiImageScreenCapture(Rectangle rect);
>
> Request your feedback on the same.
>
> Once we finalize the signature and behavior, I shall
> update the patch and send it for review.
>
> Regards,
>
> Prem
>
> *From:*Philip Race
> *Sent:* Wednesday, January 25, 2017 11:44 PM
> *To:* Alexandr Scherbatiy
> *Cc:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
> I'd like to propose some revision to the API and also have
> a question about the implementation.
>
> The question about the implementation concerns this code :-
>
> 465 AffineTransform tx = GraphicsEnvironment.
>
> 466
> getLocalGraphicsEnvironment().getDefaultScreenDevice().
>
> 467
> getDefaultConfiguration().getDefaultTransform();
>
> 468 double uiScaleX = tx.getScaleX();
>
> 469 double uiScaleY = tx.getScaleY();
>
>
> Is Robot only capable of a screen capture from the default
> screen ? I hope not.
> So I would expect that where there are two screens with
> different DPI settings/transforms
> the logic in here will be sensitive to the target screen.
> And what happens if the target rectangle overlaps the edge
> between two screens ?
>
> Regarding the API, I think that it needs to explain that
> it is "not 'hi dpi" per se,
> rather that it is the non-default transform that matters.
>
> Additionally the doc should properly link to the class
> names, not just write them
> as words.
>
> The more significant API change is that the isHiDPI
> parameter is a misnomer.
> It really means something else and I think what we should
> do is delete it
> and change the method name to something else.
>
> Here is my draft :
> /**
> * Creates an image containing pixels read from the screen.
> * This image does not include the mouse cursor.
> * This method should be used in case there is a scaling
> transform from
> * user space to screen (device) space.
> * Typically this means that the display is a high
> resolution screen,
> * although strictly it means any case in which there is
> such a transform.
> * Returns a {@link java.awt.image.BufferedImage} for a
> non-scaled display and
> * a {@link java.awt.image.MultiResolutionImage} where
> there is a scaling
> * transform.
> * <p>
> * The {@code MultiResolutionImage} will have two image
> variants:
> * <ul>
> * <li> Base Image with user specified size. This is
> scaled from the screen.
> * <li> Native device resolution image with device size
> pixels.
> * </ul>
> * @param screenRect Rect to capture in screen
> coordinates
> * @return The captured image
> * @throws IllegalArgumentException if {@code
> screenRect} width and height
> * are not greater than zero
> * @throws SecurityException if {@code
> readDisplayPixels} permission
> * is not granted
> * @see SecurityManager#checkPermission
> * @see AWTPermission
> */
>
> public synchronized Image
> multiImageeScreenCapture(Rectangle screenRect);
>
> -phil.
>
> On 1/20/17, 3:20 AM, Alexandr Scherbatiy wrote:
>
> On 1/19/2017 3:57 PM, Prem Balakrishnan wrote:
>
> Hi Alex,
>
> Please review updated patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.06/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.06/>
>
>
> Automated test validates both Robot.getPixelColor()
> and output of Robot.createScreenCapture() API's.
>
> Jtreg and JCK tests passed on build with fix across
> all the platforms(Mac, Windows and Linux) without
> causing any regression.
>
> src/java.desktop/share/classes/java/awt/Robot.java
> > 421 * @param isHiDPI Indicates if HiDPI Display
>
> There should be mention that this argument value is
> ignored when a screenshot is taken on non-HiDPI display
>
> Thanks,
> Alexandr.
>
>
>
>
>
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Thursday, January 12, 2017 2:39 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Philip Race
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
>
> > 421 * @param isHiDPI Indicates if HiDPI Display
>
> There should be mention that this argument value is
> ignored when a screenshot is taken on non-HiDPI display
>
> Please also check the the method Robot.getPixelColor(int
> x, int y) also correctly works on Mac OS X, Windows and
> Linux after the fix.
>
> Thanks,
> Alexandr.
>
> On 1/10/2017 11:54 AM, Prem Balakrishnan wrote:
>
> Hi Alex,
>
> Please review updated patch,
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.05/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.05/>
>
> updated imageOption to kCGWindowImageBestResolution
> which returns Best Resolution Image while capturing
> screen using CGWindowListCreateImage() method.
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Tuesday, January 10, 2017 1:08 AM
> *To:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Philip Race
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
>
> CGWindowListCreateImage() method which is used to
> capture a screenshot on Mac OS X by Robot has
> imageOption argument which can have value:
> kCGWindowImageBestResolution
> https://developer.apple.com/reference/coregraphics/1666230-quartz_window_services/window_image_types?language=objc
> "When capturing the window, return the best image
> resolution. The returned image size may be different
> than the screen size."
>
> Could this option help to get a high-resolution
> CGImageRef on HiDPI display?
>
> Thanks,
> Alexandr.
>
> On 12/27/2016 12:14 PM, Prem Balakrishnan wrote:
>
> Hi Alexander,
>
> Please review updated patch,
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.04/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.04/>
>
>
> I used wrong bounds while creating images,
> correct it in this patch.
>
> Regards,
>
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Wednesday, December 14, 2016 5:18 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Philip Race
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
> On 07/12/16 10:24, Prem Balakrishnan wrote:
>
>
>
>
>
>
>
>
> Hi Alexander,
>
> Please review updated patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.03/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.03/>
>
> I used a simple app [1] to create a screenshot
> of a frame on Mac OS X:
> Rectangle rect = frame.getBounds();
> rect.setLocation(frame.getLocationOnScreen());
> BufferedImage img =
> robot.createScreenCapture(rect);
>
> It takes only bottom right quarter of the frame [2].
>
> Is it possible to use some API that makes a
> screenshot and returns an NSImage on Mac OS X?
> In this case it would be possible to get a high
> resolution representation from the NSImage and
> return it in the same way as it is updated on
> Windows and Linux.
>
> [1]
> http://cr.openjdk.java.net/~alexsch/8162959/screenshot/RobotScreenshot.java
> <http://cr.openjdk.java.net/%7Ealexsch/8162959/screenshot/RobotScreenshot.java>
> [2]
> http://cr.openjdk.java.net/~alexsch/8162959/screenshot/screenshot.png
> <http://cr.openjdk.java.net/%7Ealexsch/8162959/screenshot/screenshot.png>
>
> Thanks,
> Alexandr.
>
>
>
>
>
>
>
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Monday, November 21, 2016 8:10 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>; Phil Race
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
> On 11/16/2016 8:46 AM, Prem Balakrishnan wrote:
>
>
>
>
>
>
>
>
>
> Hi Alexander,
>
> Please review update patch as per review comments.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.02/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.02/>
>
> With this patch,
> Robot.createScreenCapture(Rectangle) method
> returns a scaled down image on the HiDPI display.
>
>
> - The native part on Mac OS X and Linux should be
> updated as well.
>
> - 416 * Returns BufferedImage for Non-HiDPI
> display and MultiResolutionImage
> 417 * for HiDPI display with two resolution
> variants.
>
> There should be added an explanation what is the
> content of the first and the second resolution
> variant.
>
> Thanks,
> Alexandr.
>
>
>
>
>
>
>
>
>
>
> Regards,
>
> Prem
>
> *From:*Alexandr Scherbatiy
> *Sent:* Thursday, November 03, 2016 4:05 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
> On 11/2/2016 1:57 PM, Prem Balakrishnan wrote:
>
>
>
>
>
>
>
>
>
>
> Hi Alexander,
>
> Please review updated patch.
>
> http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.01/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.01/>
>
> Added a new public API “*Image
> createHiDPIScreenCapture(Rectangle screenRect)”.*
>
> Returns an ordinary screenshot(BufferedImage) if
> the UI scale is 1.
>
> Returns MultiResolutionImage for HiDPI display
> with two resolution variants,
>
> 1.Low Resolution/base image with user input width
> and height, I have used interpolation algorithm
> for scaling , adapted from JavaFX Robot
> (http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc),
>
> 2.High Resolution image with scaled width and height .
>
> - Please, check that the
> Robot.createScreenCapture(Rectangle) method
> returns a scaled down image on the HiDPI display
> - Probably existing Java methods can be used for
> an image scaling.
> For example, there is the
> Image.getScaledInstance(int width, int height, int
> hints) method.
> Or may be it is better just to create an image
> with required size and draw the high-resolution
> image into it using a specific scale and rendering
> hints.
>
> Thanks,
> Alexandr.
>
>
>
>
>
>
>
>
>
>
>
> Regards,
>
> Prem
>
> *From:*Alexander Scherbatiy
> *Sent:* Thursday, October 13, 2016 3:21 PM
> *To:* Prem Balakrishnan; Sergey Bylokhov;
> awt-dev at openjdk.java.net
> <mailto:awt-dev at openjdk.java.net>
> *Subject:* Re: Review Request JDK:-8162959 [HiDPI]
> screenshot artifacts using AWT Robot
>
> On 06/10/16 15:28, Prem Balakrishnan wrote:
>
> Hi*,*
>
> **
>
> Please review fix for JDK 9,
>
> *Bug:*https://bugs.openjdk.java.net/browse/JDK-8162959
>
>
> *Webrev:*http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.00/
> <http://cr.openjdk.java.net/%7Epkbalakr/8162959/webrev.00/>
>
>
> I have adapted the same fix as used for JavaFX
> Robot
>
> *Bug: *JDK-8162783
> <https://bugs.openjdk.java.net/browse/JDK-8162783>.
>
> *Patch:
> *http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/89a5de54b7dc
>
> New Public API ” BufferedImage
> createScreenCapture(Rectangle screenRect,
> boolean isHiDPI)”is added,
>
> Which will have a parameter to specify if HiDPI.
>
> It is better to a add public method which returns
> MultiResolution image on HiDPI display and
> consists of two resoltion variants
> - base image which has size requested by a user
> - high-resolution image which creates an
> original screen capture
>
> The proposed by your algorithm can be applied to
> the base image.
> For more details see JDK-8020618 [macosx]
> java.awt.Robot makes blurry screen captures on Retina
>
> Thanks,
> Alexandr.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Regards,
>
> Prem
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20170213/bc56692f/attachment-0001.html>
More information about the awt-dev
mailing list