Re: [awt-dev] Request for Approval and Review: JDK-8140329 [TEST BUG] java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java

[Ambarish Rapte]

Hi Rahul,

    Fix looks good to me. +1

 

Regards,

Ambarish

 

From: Rahul Singh 
Sent: Thursday, January 12, 2017 12:11 PM
To: Ambarish Rapte; awt-dev@openjdk.java.net
Subject: Re:  [awt-dev] Request for Approval and Review: JDK-8140329 
[TEST BUG] 
java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java

 

Hi Ambarish,

omitted unused file GenerateTestImage.java from the patch.
http://cr.openjdk.java.net/~vagarwal/8140329/webrev_03/

-Regards,
Rahul Singh

 

On 2017-01-11 1:40 PM, Ambarish Rapte wrote:

Hi Rahul,

    Fix looks good.

    But I think the file GenerateTestImage.java should be omitted 
from patch as it does not have any fix related change.

 

Regards,

Ambarish

    

 

From: Rahul Singh 
Sent: Friday, January 06, 2017 11:22 AM
To: HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net
Subject: Re:  [awt-dev] Request for Approval and Review: JDK-8140329 
[TEST BUG] 
java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java

 

Hi all,
The "user.dir" is saving the generated image in a common folder scratch whereas 
"test.classes" is saving it to a specific folder. Compiling the test file 
before running it is actually solving the problem.

 HYPERLINK 
"http://cr.openjdk.java.net/%7Evagarwal/8140329/webrev_02/"http://cr.openjdk.java.net/~vagarwal/8140329/webrev_02/

Regards,
Rahul Singh

 

On 1/4/2017 5:32 PM, Rahul Singh wrote:

Hi Ajit,
Changes made
HYPERLINK 
"http://cr.openjdk.java.net/%7Evagarwal/8140329/webrev_01/"http://cr.openjdk.java.net/~vagarwal/8140329/webrev_01/

Regards,
Rahul Singh

 

On 1/4/2017 10:38 AM, Ajit Ghaisas wrote:

The fix looks good.

 

I suggest to replace wildcard import statements with specific ones in both the 
files in webrev.

 

Regards,

Ajit

 

From: Rahul Singh 
Sent: Tuesday, January 03, 2017 6:17 PM
To: HYPERLINK "mailto:awt-dev@openjdk.java.net"awt-dev@openjdk.java.net
Subject:  [awt-dev] Request for Approval and Review: JDK-8140329 [TEST 
BUG] java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java

 

Hi All,
 
Please review the fix for the bug: HYPERLINK 
"https://bugs.openjdk.java.net/browse/JDK-7146533"JDK-8140329 [TEST BUG]
The test java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java 
fails to create test.png in the given path by GenerateTestImage.java utility. I 
used "user.dir" to obtain the path.
 
Bug Link: HYPERLINK 
"https://bugs.openjdk.java.net/browse/JDK-7146533"https://bugs.openjdk.java.net/browse/JDK-8140329
 
The webrev is : HYPERLINK 
"http://cr.openjdk.java.net/%7Evagarwal/8140329/webrev/"http://cr.openjdk.java.net/~vagarwal/8140329/webrev/
 
Regards,
 
Rahul Singh

 

 

 

Re: Review Request JDK:-8162959 [HiDPI] screenshot artifacts using AWT Robot

[Alexandr Scherbatiy]

> 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/ 



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@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/


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@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/


  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


  [2]
http://cr.openjdk.java.net/~alexsch/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@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/


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@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/


Added a new public API “*Image createHiDPIScreenCapture(Rectangle
  

Re: [9] Review request for 8171909: [PIT] on Windows, failure of java/awt/Dialog/DialogAboveFrame/DialogAboveFrameTest.java

[Yuri Nesterenko]

Fine with me: runs as expected even on Win10.

-yan

On 01/11/2017 04:53 PM, Sergey Bylokhov wrote:

Looks fine.
Yuri can you please take a look also? Thanks.




Hello,

Could you review a fix for jdk9, please?

bug: https://bugs.openjdk.java.net/browse/JDK-8171909
webrev: http://cr.openjdk.java.net/~dmarkov/8171909/webrev.00/

Problem description:
The test displays a frame and a dialog; then it checks the pixel's
color to test whether the dialog is above the frame or not. It looks
like drawing operation on Windows works a bit slowly than on OSX and
the pixel doesn't have desired color when we examine it.

Fix:
The test should use Util.testPixelColor() from regtesthelpers package
which is specially designed for asynchronous window manager.

Thanks,
Dmitry

Re: Proposal on enhancing MouseWheelEvent to include absolute scrolling delta

[Pavel Fatin]

Hi Sergey,

The absolute deltas are /optional /and provided only when they are 
available, so there's no need to generate these values on all platforms, 
for all events. For example, mouse wheel doesn't generate absolute 
deltas, because a wheel step naturally corresponds to a line (or several 
discrete lines). We can use 0.0 value to indicate the absence of 
absolute delta (so, if some platform doesn't provide absolute deltas, 
0.0 is a valid value, and the platform is still "supported").


The Apple's scrollingDeltaY description tells 
: 
"When hasPreciseScrollingDeltas is false, /multiply /the value returned 
by this method by the line or row height. Otherwise /scroll by /the 
returned amount". That particular API uses a /single /variable to hold 
both relative- and absolute deltas, together with the additional flag 
that tells how to interpret the value (i.e. when 
hasPreciseScrollingDeltas is false, scrollingDeltaY contains deltaY). 
It's just a slightly different way to represent the two kinds of data, 
using a separate boolean flag, instead of the 0.0 marker (i.e. it puts 
the two disparate values into a single variable and then provides a way 
to distinguish them).


Apple doesn't explicitly specify units for the absolute deltas (it only 
tells to "scroll /by/ the returned amount"). The Windows' Direct 
Manipulation API states that the absolute transformations are given in 
device-independent pixels. It seems that we can also specify 
"device-independent pixels" explicitly.


There's no reliable way to convert absolute deltas to relative deltas, 
because the relative deltas are /relative /to arbitrary scrolling unit 
size, which is not a part of input, but a part of the content rendering 
(which might not even exist). OS generates the two kinds of data 
separately, and both spatial- and temporal resolutions differ 
considerably (so, an attempt to somehow channel the absolute delta into 
the already existing, relative one, can potentially raise compatibility 
/ performance problems).


We have /already /implemented "smooth scrolling" in IDEA itself. One 
doesn't even need high-precision input to render the transitions 
smoothly, yet high-resolution input is useful to increase the 
positioning precision, to transfer the dynamics better and to reduce the 
input latency.


Besides, there's no much sense in trying to "squeeze" the absolute delta 
into the relative one as "a temporary solution" – just as well, we can 
temporary add the absolute deltas to JetBrains Runtime directly, which 
seems to be a more reliable and a better-performing solution that really 
delivers Mac-like scrolling feel.


The central purpose of the proposal is not to create some temporary 
workaround for a particular task, but rather to enhance and improve the 
Java itself, so it can be up-to-date with the state of modern hardware / 
OSes. If JDK 9 is already frozen, I hope that the idea can still be 
useful for the next versions.



On 11.01.2017 16:18, Sergey Bylokhov wrote:

H, Pavel.
Thanks for this proposal.
First of all if you have a plan to implement smooth scrolling in the 
jdk9, then it will be good to use only existing API. (We already had a 
the feature freeze).
So for now a solution will be better to implement the fix via 
getPreciseWheelRotation 
(). 
At least in this case you will be able to implement it only on 
Mac/win, but if you provide the new API then it should be supported on 
all platforms.
Is it possible to convert absolute data to the deltas? What is the 
difference between absolute data and deltas? The main problem which I 
see here is that we have no strict definition of units which we use 
for scrolling(ticks, pixels, lines or 2-pixels on the retina etc).



Hi All,

Next follows a proposal on enhancingMouseWheelEventto include 
absolute scrolling delta.


My name is Pavel Fatin, I work at JetBrains (IntelliJ IDEA). Although 
this is my first message here, I have been working with Java / AWT / 
Swing since Java 1.2 and have some in-depth experience (for example, 
my research onlow-latency painting in AWT and Swing 
).


Because we at JetBrains receive manyrequests 
to implement 
smooth-scrolling in IDEA, as an experiment, weextended 
our 
custom scroll pane class to 
handleMouseWheelEvent'sgetPreciseWheelRotation() 
data 
(that method was introduced in Java 7, but it’s not yet used by AWT / 
Swing directly). As a result, the scrolling "smoothness" and 
precision improved substantially, however on OS X it was still