Review request for : JDK-8137087 [TEST BUG] java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh

[Rahul Singh]

Hi All,

Kindly review the fix for the bug:JDK-8137087 
  [TEST BUG]
The 
testjava/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh
  needed few changes to be run in the Cygwin Environment.

Bug Link: https://bugs.openjdk.java.net/browse/JDK-8137087

The webrev is : http://cr.openjdk.java.net/~srastogi/rahul/8137087/webrev.00/

Regards,
Rahul Singh

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

[Alexandr Scherbatiy]

The fix looks good to me.

Thanks,
Alexandr.

On 1/23/2017 9:04 AM, Prem Balakrishnan wrote:


Hi Alex,

Please review updated patch as per review comments.

http://cr.openjdk.java.net/~pkbalakr/8162959/webrev.07/ 



Regards,

Prem

*From:*Alexandr Scherbatiy
*Sent:* Friday, January 20, 2017 4:50 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 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/


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


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]

Re: RFR: 8167228: Update to libpng 1.6.28

[Alexander Zvegintsev]

+1

Thanks,
Alexander.

On 23/01/2017 18:35, Sergey Bylokhov wrote:

Looks fine.


Webrev: http://cr.openjdk.java.net/~prr/8167228/

This fix updates libpng in JDK 9 to the current version 1.6.28.
Aside from updating to these files there are few changes to note

(1) The CHANGES file has previously inexplicably included a GPL and Oracle 
Copyright.
Nothing whatsoever in here is from Oracle and it is not even source code.
I deleted that notice.

(2) We have always compiled without "WRITE" support, yet included all the source
files that are used only for writing. libpng is used only by splashscreen (it 
is compiled
into the library) and that has no need for write support anyway.
So I decided we should stop importing these files to remove any future questions
about issues in PNG writing ...
Note that the options to disable WRITE support are configured via pnglibconf.h,
more on that in a moment.

(3) In addition pngtest.c is removed. This is wholly unnecessary()

(4) pnglibconf.h is also updated to no longer automatically decode certain
compressed chunks which we don't use anyway ... this will improve performance
and robustness.

Future updates, and indeed any backports to 8u should follow the above.

JPRT has built this for all platforms and all SplashScreen tests have passed ..
although I think only a few really test png support.

-phil.

Re: RFR: 8167228: Update to libpng 1.6.28

[Sergey Bylokhov]

Looks fine.

> 
> Webrev: http://cr.openjdk.java.net/~prr/8167228/
> 
> This fix updates libpng in JDK 9 to the current version 1.6.28.
> Aside from updating to these files there are few changes to note
> 
> (1) The CHANGES file has previously inexplicably included a GPL and Oracle 
> Copyright.
> Nothing whatsoever in here is from Oracle and it is not even source code.
> I deleted that notice.
> 
> (2) We have always compiled without "WRITE" support, yet included all the 
> source
> files that are used only for writing. libpng is used only by splashscreen (it 
> is compiled
> into the library) and that has no need for write support anyway.
> So I decided we should stop importing these files to remove any future 
> questions
> about issues in PNG writing ...
> Note that the options to disable WRITE support are configured via 
> pnglibconf.h,
> more on that in a moment.
> 
> (3) In addition pngtest.c is removed. This is wholly unnecessary()
> 
> (4) pnglibconf.h is also updated to no longer automatically decode certain
> compressed chunks which we don't use anyway ... this will improve performance
> and robustness.
> 
> Future updates, and indeed any backports to 8u should follow the above.
> 
> JPRT has built this for all platforms and all SplashScreen tests have passed 
> ..
> although I think only a few really test png support.
> 
> -phil.

Re: Fix for precise scrolling on Mac Sierra 10.12.2

[Sergey Malenkov]

Pavel,

Could you please provide your tests and their results for different
versions of MacOS, including 10.12.1 and 10.12.2?

Thanks,
SAM

On Thu, Jan 19, 2017 at 6:28 PM, Pavel Fatin  wrote:
> Hi Sergey,
>
> The provided list of numbers gives the impression that deltaY =~ SUM(0.1 *
> scrollingDeltaY) and then the code uses 0.1 as a fixed multiplier to
> translate between the values. However, tests show that it's not the case –
> in reality, there's no such a linear mapping between the two values, and
> SUM(0.1 * scrollingDeltaY) might differ from deltaY significantly (x2-x5),
> especially on slow scrolling.
>
>
> On 17.01.2017 0:34, Sergey Malenkov wrote:
>
> Hello all,
>
> A precise scrolling (introduced in Sierra) caused a fast scrolling in
> old applications including Java. It was fixed in JDK by introducing an
> accumulator for deltas. But Apple fixed this issue in 10.12.2 by
> introducing own accumulator. So, the deltaX/Y do not correspond to the
> scrollingDeltaX/Y for now. It does not affect current scrolling
> implementation in Swing, but it breaks precise scrolling values in
> MouseWheelEvent.
>
> Java API assumes that all scrolling deltas are declared in terms of
> unit scroll (i.e. a line height), so we should use deltaX/Y, but not
> recommended scrollingDeltaX/Y. But since 10.12.2 these values are not
> precise. Moreover, these values do not correspond to scrolling delta.
>
> Actual Results:
> deltaY =0.4, scrollingDeltaY =   5,
> deltaY =0.4, scrollingDeltaY =   5,
> deltaY =0.0, scrollingDeltaY =   5,
> deltaY =0.0, scrollingDeltaY =   4,
> deltaY =0.0, scrollingDeltaY =   4,
> deltaY =1.4, scrollingDeltaY =   4,
> deltaY =0.0, scrollingDeltaY =   3,
> deltaY =0.0, scrollingDeltaY =   3,
> deltaY =0.0, scrollingDeltaY =   3,
> deltaY =0.0, scrollingDeltaY =   3,
> deltaY =1.1, scrollingDeltaY =   2,
> deltaY =0.0, scrollingDeltaY =   2,
> deltaY =0.0, scrollingDeltaY =   2,
> deltaY =0.0, scrollingDeltaY =   2,
> deltaY =0.0, scrollingDeltaY =   1,
> deltaY =0.0, scrollingDeltaY =   0,
>
> Expected Results:
> deltaY =0.5, scrollingDeltaY =   5,
> deltaY =0.5, scrollingDeltaY =   5,
> deltaY =0.5, scrollingDeltaY =   5,
> deltaY =0.4, scrollingDeltaY =   4,
> deltaY =0.4, scrollingDeltaY =   4,
> deltaY =0.4, scrollingDeltaY =   4,
> deltaY =0.3, scrollingDeltaY =   3,
> deltaY =0.3, scrollingDeltaY =   3,
> deltaY =0.3, scrollingDeltaY =   3,
> deltaY =0.3, scrollingDeltaY =   3,
> deltaY =0.2, scrollingDeltaY =   2,
> deltaY =0.2, scrollingDeltaY =   2,
> deltaY =0.2, scrollingDeltaY =   2,
> deltaY =0.2, scrollingDeltaY =   2,
> deltaY =0.1, scrollingDeltaY =   1,
> deltaY =0.0, scrollingDeltaY =   0,
>
> I suggest to calculate delta from the corresponding scrollingDelta if
> a native event has precise scrolling deltas. Could you please review
> attached webrev.zip ?
>
>
> --
> Sincerely, Pavel



-- 
Best regards,
Sergey A. Malenkov