From philip.race at oracle.com  Thu Feb  1 20:50:47 2018
From: philip.race at oracle.com (Phil Race)
Date: Thu, 1 Feb 2018 12:50:47 -0800
Subject: [OpenJDK 2D-Dev] RFR: 8196288: Update
 src/java.desktop/share/legal/libharfbuzz.md for harfbuzz 1.7.1
Message-ID: <7bc12ea7-8a4d-195e-aeda-0c543ea3a77d@oracle.com>

bug: https://bugs.openjdk.java.net/browse/JDK-8196288
webrev: http://cr.openjdk.java.net/~prr/8196288/

This is a JDK10 doc-only fix.
The version is bumped to 1.7.1 and the (c) lines are adjusted to match
what is actually in the 1.7.1 COPYING file as approved by legal.

-phil.

From prasanta.sadhukhan at oracle.com  Fri Feb  2 03:07:04 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Fri, 2 Feb 2018 08:37:04 +0530
Subject: [OpenJDK 2D-Dev] RFR: 8196288: Update
 src/java.desktop/share/legal/libharfbuzz.md for harfbuzz 1.7.1
In-Reply-To: <7bc12ea7-8a4d-195e-aeda-0c543ea3a77d@oracle.com>
References: <7bc12ea7-8a4d-195e-aeda-0c543ea3a77d@oracle.com>
Message-ID: <04cc55e8-7131-b973-ad0d-8c9c074b2572@oracle.com>

+1

Regards
Prasanta
On 2/2/2018 2:20 AM, Phil Race wrote:
> bug: https://bugs.openjdk.java.net/browse/JDK-8196288
> webrev: http://cr.openjdk.java.net/~prr/8196288/
>
> This is a JDK10 doc-only fix.
> The version is bumped to 1.7.1 and the (c) lines are adjusted to match
> what is actually in the 1.7.1 COPYING file as approved by legal.
>
> -phil.


From Alan.Bateman at oracle.com  Sat Feb  3 09:35:41 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 3 Feb 2018 09:35:41 +0000
Subject: [OpenJDK 2D-Dev] Fwd: [PATCH] Fix compiler warnings with newer GCC
	7.2.1
In-Reply-To: <b1965adc-2709-4241-85f9-1d0d022eca97@oracle.com>
References: <b1965adc-2709-4241-85f9-1d0d022eca97@oracle.com>
Message-ID: <4c5248f3-e78d-31ba-c892-fd7df1d027af@oracle.com>


This was sent to core-libs-dev, I assume it was meant for 2d-dev and 
serviceability-dev.

-------- Forwarded Message --------
Subject: 	[PATCH] Fix compiler warnings with newer GCC 7.2.1
Date: 	Fri, 2 Feb 2018 16:12:08 -0800
From: 	Indu Bhagat <indu.bhagat at oracle.com>
To: 	core-libs-dev at openjdk.java.net



This patch fixes a few of the compiler warnings when using gcc 7.2.1.

In general there are many other warnings (a majority of which are implicit fallthrough warnings in jdk.crypto.ec package's ecp_*.c files and java.desktop package's splashscreen_gfx_impl.h file).
I can post them if there is interest.
Most warnings, however, look benign (modulo some warnings about unintialized access that I cannot comment on; they need that the code be thoroughly understood).
libfdlibm misleading indentation warnings are already knownhttp://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html

Thanks

----------------------------------------------
The patch fixes the following warnings :

1. <jdk-dev>/jdk/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: In function ?mask_s2u?:
    <jdk-dev>/jdk/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:389:22: warning: left shift of negative value [-Wshift-negative-value]
      *mask = htonl(-1 << (32 - m));
                       ^
2. <jdk-dev>/jdk/src/java.desktop/share/native/libjavajpeg/jdphuff.c: In function ?decode_mcu_AC_refine?:
    <jdk-dev>/jdk/src/java.desktop/share/native/libjavajpeg/jdphuff.c:505:17: warning: left shift of negative value [-Wshift-negative-value]
    int m1 = (-1) << cinfo->Al;   /* -1 in the bit position being coded*/
                  ^~
3. <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc: In function ?void position_mark(const hb_ot_shape_plan_t*, hb_font_t*, hb_buffer_t*, hb_glyph_extents_t&, unsigned int, unsigned int)?:
    <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:223:14: warning: this statement may fall through [-Wimplicit-fallthrough=]
        } else if (buffer->props.direction == HB_DIRECTION_RTL) {
               ^~
    <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:229:5: note: here
      default:
      ^~~~~~~
    <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:261:27: warning: this statement may fall through [-Wimplicit-fallthrough=]
        base_extents.height -= y_gap;
        ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
    <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:264:5: note: here
      case HB_UNICODE_COMBINING_CLASS_ATTACHED_BELOW_LEFT:
      ^~~~
    <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:282:27: warning: this statement may fall through [-Wimplicit-fallthrough=]
        base_extents.height -= y_gap;
        ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
    <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:285:5: note: here
      case HB_UNICODE_COMBINING_CLASS_ATTACHED_ABOVE:
      ^~~~
-----------

diff --git a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
--- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
+++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
@@ -158,6 +158,9 @@
      */
  #  include <sal.h>
  #  define HB_FALLTHROUGH __fallthrough
+#elif __GNUC__ >= 7
+   /* GNU fallthrough attribute is available from GCC7 */
+#  define HB_FALLTHROUGH __attribute__((fallthrough))
  #else
  #  define HB_FALLTHROUGH /* FALLTHROUGH */
  #endif
diff --git a/src/java.desktop/share/native/libjavajpeg/jdphuff.c b/src/java.desktop/share/native/libjavajpeg/jdphuff.c
--- a/src/java.desktop/share/native/libjavajpeg/jdphuff.c
+++ b/src/java.desktop/share/native/libjavajpeg/jdphuff.c
@@ -501,8 +501,10 @@
  {
    phuff_entropy_ptr entropy = (phuff_entropy_ptr) cinfo->entropy;
    int Se = cinfo->Se;
-  int p1 = 1 << cinfo->Al;      /* 1 in the bit position being coded */
-  int m1 = (-1) << cinfo->Al;   /* -1 in the bit position being coded */
+  /* 1 in the bit position being coded */
+  int p1 = 1 << cinfo->Al;
+  /* -1 in the bit position being coded */
+  int m1 = (int)((unsigned)(~0) << cinfo->Al);
    register int s, k, r;
    unsigned int EOBRUN;
    JBLOCKROW block;
diff --git a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
--- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
+++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
@@ -386,7 +386,7 @@
         return instr;
      }
  
-    *mask = htonl(-1 << (32 - m));
+    *mask = htonl((uint32_t)(~0) << (32 - m));
      return s;
  }
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180203/76a7f986/attachment.html>

From philip.race at oracle.com  Sat Feb  3 13:47:11 2018
From: philip.race at oracle.com (Philip Race)
Date: Sat, 03 Feb 2018 05:47:11 -0800
Subject: [OpenJDK 2D-Dev] Fwd: [PATCH] Fix compiler warnings with newer
 GCC 7.2.1
In-Reply-To: <4c5248f3-e78d-31ba-c892-fd7df1d027af@oracle.com>
References: <b1965adc-2709-4241-85f9-1d0d022eca97@oracle.com>
 <4c5248f3-e78d-31ba-c892-fd7df1d027af@oracle.com>
Message-ID: <5A75BD5F.5080309@oracle.com>

jpeg + harfbuzz are imported libraries. There's no point in a source fix 
in JDK'scopy as
it will get overwritten when we upgrade. No way we are tracking such 
patches to reapply them.

If warnings there are an issue either update the makefiles or use 
disable-warnings-as-errors
... and perhaps report the issue upstream ..

-phil.

On 2/3/18, 1:35 AM, Alan Bateman wrote:
>
> This was sent to core-libs-dev, I assume it was meant for 2d-dev and 
> serviceability-dev.
>
> -------- Forwarded Message --------
> Subject: 	[PATCH] Fix compiler warnings with newer GCC 7.2.1
> Date: 	Fri, 2 Feb 2018 16:12:08 -0800
> From: 	Indu Bhagat <indu.bhagat at oracle.com>
> To: 	core-libs-dev at openjdk.java.net
>
>
>
> This patch fixes a few of the compiler warnings when using gcc 7.2.1.
>
> In general there are many other warnings (a majority of which are implicit fallthrough warnings in jdk.crypto.ec package's ecp_*.c files and java.desktop package's splashscreen_gfx_impl.h file).
> I can post them if there is interest.
> Most warnings, however, look benign (modulo some warnings about unintialized access that I cannot comment on; they need that the code be thoroughly understood).
> libfdlibm misleading indentation warnings are already knownhttp://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html
>
> Thanks
>
> ----------------------------------------------
> The patch fixes the following warnings :
>
> 1.<jdk-dev>/jdk/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: In function ?mask_s2u?:
>     <jdk-dev>/jdk/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:389:22: warning: left shift of negative value [-Wshift-negative-value]
>       *mask = htonl(-1<<  (32 - m));
>                        ^
> 2.<jdk-dev>/jdk/src/java.desktop/share/native/libjavajpeg/jdphuff.c: In function ?decode_mcu_AC_refine?:
>     <jdk-dev>/jdk/src/java.desktop/share/native/libjavajpeg/jdphuff.c:505:17: warning: left shift of negative value [-Wshift-negative-value]
>     int m1 = (-1)<<  cinfo->Al;   /* -1 in the bit position being coded*/
>                   ^~
> 3.<jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc: In function ?void position_mark(const hb_ot_shape_plan_t*, hb_font_t*, hb_buffer_t*, hb_glyph_extents_t&, unsigned int, unsigned int)?:
>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:223:14: warning: this statement may fall through [-Wimplicit-fallthrough=]
>         } else if (buffer->props.direction == HB_DIRECTION_RTL) {
>                ^~
>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:229:5: note: here
>       default:
>       ^~~~~~~
>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:261:27: warning: this statement may fall through [-Wimplicit-fallthrough=]
>         base_extents.height -= y_gap;
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:264:5: note: here
>       case HB_UNICODE_COMBINING_CLASS_ATTACHED_BELOW_LEFT:
>       ^~~~
>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:282:27: warning: this statement may fall through [-Wimplicit-fallthrough=]
>         base_extents.height -= y_gap;
>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:285:5: note: here
>       case HB_UNICODE_COMBINING_CLASS_ATTACHED_ABOVE:
>       ^~~~
> -----------
>
> diff --git a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
> @@ -158,6 +158,9 @@
>       */
>   #  include<sal.h>
>   #  define HB_FALLTHROUGH __fallthrough
> +#elif __GNUC__>= 7
> +   /* GNU fallthrough attribute is available from GCC7 */
> +#  define HB_FALLTHROUGH __attribute__((fallthrough))
>   #else
>   #  define HB_FALLTHROUGH /* FALLTHROUGH */
>   #endif
> diff --git a/src/java.desktop/share/native/libjavajpeg/jdphuff.c b/src/java.desktop/share/native/libjavajpeg/jdphuff.c
> --- a/src/java.desktop/share/native/libjavajpeg/jdphuff.c
> +++ b/src/java.desktop/share/native/libjavajpeg/jdphuff.c
> @@ -501,8 +501,10 @@
>   {
>     phuff_entropy_ptr entropy = (phuff_entropy_ptr) cinfo->entropy;
>     int Se = cinfo->Se;
> -  int p1 = 1<<  cinfo->Al;      /* 1 in the bit position being coded */
> -  int m1 = (-1)<<  cinfo->Al;   /* -1 in the bit position being coded */
> +  /* 1 in the bit position being coded */
> +  int p1 = 1<<  cinfo->Al;
> +  /* -1 in the bit position being coded */
> +  int m1 = (int)((unsigned)(~0)<<  cinfo->Al);
>     register int s, k, r;
>     unsigned int EOBRUN;
>     JBLOCKROW block;
> diff --git a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
> @@ -386,7 +386,7 @@
>          return instr;
>       }
>
> -    *mask = htonl(-1<<  (32 - m));
> +    *mask = htonl((uint32_t)(~0)<<  (32 - m));
>       return s;
>   }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180203/22c2a1e0/attachment.html>

From erik.joelsson at oracle.com  Mon Feb  5 22:54:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 5 Feb 2018 14:54:11 -0800
Subject: [OpenJDK 2D-Dev] RFR: JDK-8196803: Fix build warnings in jdk
	libraries with Xcode 9
Message-ID: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>

When building with Xcode 9, we get some warnings triggered in jdk 
libraries. This patch tries to fix them. See bug description for more 
details on each of them. In short the following things are addressed:

In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove 
the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's 
relevant. The source needs to compile against the headers that are 
present. This was touched on earlier in this thread: 
http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html 
and when going back, it's quite clear to me that the fix done there was 
incorrect.

In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we 
can't modify the source file itself, so here I've added a wrapper for 
zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches 
what's available on the Macosx version we are building for. This type of 
override can be brittle but seems to work OK in this case. While doing 
this, I also refactored the handling of libz cflags and libs. They are 
better set and exported from configure to be globally available in the 
build.

We also get warnings when linking static libraries. These are easily 
fixed by adding the -mmacosx-version-min= arguments on these command 
lines just like we do for linking shared libraries and executables. I 
solved this by setting ARFLAGS and actually use that variable.

Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html

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

/Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180205/9274aa5d/attachment.html>

From tim.bell at oracle.com  Tue Feb  6 00:00:36 2018
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 05 Feb 2018 16:00:36 -0800
Subject: [OpenJDK 2D-Dev] RFR: JDK-8196803: Fix build warnings in jdk
 libraries with Xcode 9
In-Reply-To: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
References: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
Message-ID: <5A78F024.7040102@oracle.com>

Erik:


> Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196803

Looks good.

/Tim



From philip.race at oracle.com  Tue Feb  6 08:43:13 2018
From: philip.race at oracle.com (Philip Race)
Date: Tue, 06 Feb 2018 14:13:13 +0530
Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8195131: Dead code removal for
 changes present in JDK-8176795
In-Reply-To: <7338f346-424e-40c2-a542-3c0dbc774dd6@default>
References: <ee15827c-3adb-496a-b31f-0ba6319c25dc@default>
 <7338f346-424e-40c2-a542-3c0dbc774dd6@default>
Message-ID: <5A796AA1.60901@oracle.com>

Looks fine. If anyone needs this in the future they can add back this or 
an overload that does the pre-multiplication.

-phil.

On 1/18/18, 12:44 PM, Prahalad Kumar Narayanan wrote:
> Hello Jay
>
> I understand that the last argument to XRColor.setColorValues (int pixel, boolean pre) is set to 'true' at all caller sites.
> This results in block of code within if (!pre) { ... } not being used at all.
>
>     97         if (!pre) {
>     98             double alphaMult = XRUtils.XFixedToDouble(alpha);
>     99             this.red = (int) (red * alphaMult);
>   100             this.green = (int) (green * alphaMult);
>   101             this.blue = (int) (blue * alphaMult);
>   102         }
>
> Though the snippet is un-used presently, it is not an obsolete code because it helps to create XRColor from non pre-mulitplied alpha color.
> Hence, I would wish to retain the code from future perspective.
>
> The consolation here is that, we are addressing code removal as a separate fix. Thus a revert operation will be easy if need arises in future.
> So this should be fine. Kindly wait on other reviewers' opinion as well.
>
> Thank you
> Have a good day
>
> Prahalad N.
>
>
> ----- Original Message -----
> From: Jayathirth D V
> Sent: Thursday, January 18, 2018 11:49 AM
> To: 2d-dev
> Subject: [OpenJDK 2D-Dev] [11] RFR JDK-8195131: Dead code removal for changes present in JDK-8176795
>
> Hello All,
>
> Please review the following fix in JDK11 :
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8195131
> Webrev : http://cr.openjdk.java.net/~jdv/8195131/webrev.00/
>
> Issue: After changes present in https://bugs.openjdk.java.net/browse/JDK-8176795 the Non-Premultiplied alpha color to Premultiplied alpha color conversion code present under XRColor.setColorValues() is not reachable.
>
> Solution: While fixing https://bugs.openjdk.java.net/browse/JDK-8176795 we decided that we will remove this unreachable/dead code in separate bug so that in future if we need this color conversion code it will be easy to revert. As part of the fix dead code is removed along with minor changes at different files where XRColor.setColorValues() is used.
>
> Thanks,
> Jay

From magnus.ihse.bursie at oracle.com  Tue Feb  6 17:35:36 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 6 Feb 2018 18:35:36 +0100
Subject: [OpenJDK 2D-Dev] RFR: JDK-8196803: Fix build warnings in jdk
 libraries with Xcode 9
In-Reply-To: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
References: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
Message-ID: <e7209e38-1984-bcd0-7186-4ffaf30c5150@oracle.com>


On 2018-02-05 23:54, Erik Joelsson wrote:
> When building with Xcode 9, we get some warnings triggered in jdk 
> libraries. This patch tries to fix them. See bug description for more 
> details on each of them. In short the following things are addressed:
>
> In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove 
> the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's 
> relevant. The source needs to compile against the headers that are 
> present. This was touched on earlier in this thread: 
> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html 
> and when going back, it's quite clear to me that the fix done there 
> was incorrect.
>
> In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we 
> can't modify the source file itself, so here I've added a wrapper for 
> zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches 
> what's available on the Macosx version we are building for. This type 
> of override can be brittle but seems to work OK in this case. While 
> doing this, I also refactored the handling of libz cflags and libs. 
> They are better set and exported from configure to be globally 
> available in the build.
>
> We also get warnings when linking static libraries. These are easily 
> fixed by adding the -mmacosx-version-min= arguments on these command 
> lines just like we do for linking shared libraries and executables. I 
> solved this by setting ARFLAGS and actually use that variable.
>
> Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html
Looks good to me.

Thanks for the ZLIB cleanup. The naming and usage there has really been off.

/Magnus
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196803
>
> /Erik
>


From indu.bhagat at oracle.com  Tue Feb  6 19:00:40 2018
From: indu.bhagat at oracle.com (Indu Bhagat)
Date: Tue, 6 Feb 2018 11:00:40 -0800
Subject: [OpenJDK 2D-Dev] Fwd: [PATCH] Fix compiler warnings with newer
 GCC 7.2.1
In-Reply-To: <5A75BD5F.5080309@oracle.com>
References: <b1965adc-2709-4241-85f9-1d0d022eca97@oracle.com>
 <4c5248f3-e78d-31ba-c892-fd7df1d027af@oracle.com>
 <5A75BD5F.5080309@oracle.com>
Message-ID: <5eb1e208-bf8c-ec7e-2a75-3afc594e81d3@oracle.com>

Thanks. harfbuzz is now fixed upstream. libjpeg has acknowledged the 
patch for shift-negative-value warnings.

Can someone advise on the minor fix in libdt_socket component ?


On 02/03/2018 05:47 AM, Philip Race wrote:
> jpeg + harfbuzz are imported libraries. There's no point in a source 
> fix in JDK'scopy as
> it will get overwritten when we upgrade. No way we are tracking such 
> patches to reapply them.
>
> If warnings there are an issue either update the makefiles or use 
> disable-warnings-as-errors
> ... and perhaps report the issue upstream ..
>
> -phil.
>
> On 2/3/18, 1:35 AM, Alan Bateman wrote:
>>
>> This was sent to core-libs-dev, I assume it was meant for 2d-dev and 
>> serviceability-dev.
>>
>> -------- Forwarded Message --------
>> Subject: 	[PATCH] Fix compiler warnings with newer GCC 7.2.1
>> Date: 	Fri, 2 Feb 2018 16:12:08 -0800
>> From: 	Indu Bhagat <indu.bhagat at oracle.com>
>> To: 	core-libs-dev at openjdk.java.net
>>
>>
>>
>> This patch fixes a few of the compiler warnings when using gcc 7.2.1.
>>
>> In general there are many other warnings (a majority of which are implicit fallthrough warnings in jdk.crypto.ec package's ecp_*.c files and java.desktop package's splashscreen_gfx_impl.h file).
>> I can post them if there is interest.
>> Most warnings, however, look benign (modulo some warnings about unintialized access that I cannot comment on; they need that the code be thoroughly understood).
>> libfdlibm misleading indentation warnings are already knownhttp://mail.openjdk.java.net/pipermail/jdk9-dev/2016-June/004494.html
>>
>> Thanks
>>
>> ----------------------------------------------
>> The patch fixes the following warnings :
>>
>> 1. <jdk-dev>/jdk/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c: In function ?mask_s2u?:
>>     <jdk-dev>/jdk/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:389:22: warning: left shift of negative value [-Wshift-negative-value]
>>       *mask = htonl(-1 << (32 - m));
>>                        ^
>> 2. <jdk-dev>/jdk/src/java.desktop/share/native/libjavajpeg/jdphuff.c: In function ?decode_mcu_AC_refine?:
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libjavajpeg/jdphuff.c:505:17: warning: left shift of negative value [-Wshift-negative-value]
>>     int m1 = (-1) << cinfo->Al;   /* -1 in the bit position being coded*/
>>                   ^~
>> 3. <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc: In function ?void position_mark(const hb_ot_shape_plan_t*, hb_font_t*, hb_buffer_t*, hb_glyph_extents_t&, unsigned int, unsigned int)?:
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:223:14: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>         } else if (buffer->props.direction == HB_DIRECTION_RTL) {
>>                ^~
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:229:5: note: here
>>       default:
>>       ^~~~~~~
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:261:27: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>         base_extents.height -= y_gap;
>>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:264:5: note: here
>>       case HB_UNICODE_COMBINING_CLASS_ATTACHED_BELOW_LEFT:
>>       ^~~~
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:282:27: warning: this statement may fall through [-Wimplicit-fallthrough=]
>>         base_extents.height -= y_gap;
>>         ~~~~~~~~~~~~~~~~~~~~^~~~~~~~
>>     <jdk-dev>/jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-fallback.cc:285:5: note: here
>>       case HB_UNICODE_COMBINING_CLASS_ATTACHED_ABOVE:
>>       ^~~~
>> -----------
>>
>> diff --git a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
>> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
>> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh
>> @@ -158,6 +158,9 @@
>>       */
>>   #  include <sal.h>
>>   #  define HB_FALLTHROUGH __fallthrough
>> +#elif __GNUC__ >= 7
>> +   /* GNU fallthrough attribute is available from GCC7 */
>> +#  define HB_FALLTHROUGH __attribute__((fallthrough))
>>   #else
>>   #  define HB_FALLTHROUGH /* FALLTHROUGH */
>>   #endif
>> diff --git a/src/java.desktop/share/native/libjavajpeg/jdphuff.c b/src/java.desktop/share/native/libjavajpeg/jdphuff.c
>> --- a/src/java.desktop/share/native/libjavajpeg/jdphuff.c
>> +++ b/src/java.desktop/share/native/libjavajpeg/jdphuff.c
>> @@ -501,8 +501,10 @@
>>   {
>>     phuff_entropy_ptr entropy = (phuff_entropy_ptr) cinfo->entropy;
>>     int Se = cinfo->Se;
>> -  int p1 = 1 << cinfo->Al;      /* 1 in the bit position being coded */
>> -  int m1 = (-1) << cinfo->Al;   /* -1 in the bit position being coded */
>> +  /* 1 in the bit position being coded */
>> +  int p1 = 1 << cinfo->Al;
>> +  /* -1 in the bit position being coded */
>> +  int m1 = (int)((unsigned)(~0) << cinfo->Al);
>>     register int s, k, r;
>>     unsigned int EOBRUN;
>>     JBLOCKROW block;
>> diff --git a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>> --- a/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>> +++ b/src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c
>> @@ -386,7 +386,7 @@
>>          return instr;
>>       }
>>   
>> -    *mask = htonl(-1 << (32 - m));
>> +    *mask = htonl((uint32_t)(~0) << (32 - m));
>>       return s;
>>   }
>>   
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180206/c64339fd/attachment.html>

From chris.plummer at oracle.com  Tue Feb  6 20:06:33 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 6 Feb 2018 12:06:33 -0800
Subject: [OpenJDK 2D-Dev] Fwd: [PATCH] Fix compiler warnings with newer
 GCC 7.2.1
In-Reply-To: <5eb1e208-bf8c-ec7e-2a75-3afc594e81d3@oracle.com>
References: <b1965adc-2709-4241-85f9-1d0d022eca97@oracle.com>
 <4c5248f3-e78d-31ba-c892-fd7df1d027af@oracle.com>
 <5A75BD5F.5080309@oracle.com>
 <5eb1e208-bf8c-ec7e-2a75-3afc594e81d3@oracle.com>
Message-ID: <73005887-dd65-f81e-6b86-7806d4813a69@oracle.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180206/b1a9df89/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Tue Feb  6 20:54:05 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 6 Feb 2018 12:54:05 -0800
Subject: [OpenJDK 2D-Dev] RFR: JDK-8196803: Fix build warnings in jdk
 libraries with Xcode 9
In-Reply-To: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
References: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
Message-ID: <42c4a88f-0a22-b9b8-5549-964411c26df3@oracle.com>

Hi, Erik.
Why XCode 9 was selected? It seems that 9.2 is the latest one.
9.2 produces some additional warnings even after this fix.

On 05/02/2018 14:54, Erik Joelsson wrote:
> When building with Xcode 9, we get some warnings triggered in jdk 
> libraries. This patch tries to fix them. See bug description for more 
> details on each of them. In short the following things are addressed:
> 
> In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, remove 
> the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think that's 
> relevant. The source needs to compile against the headers that are 
> present. This was touched on earlier in this thread: 
> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html 
> and when going back, it's quite clear to me that the fix done there was 
> incorrect.
> 
> In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, we 
> can't modify the source file itself, so here I've added a wrapper for 
> zlib.h that rewrites the ZLIB_VERNUM macro to a version that matches 
> what's available on the Macosx version we are building for. This type of 
> override can be brittle but seems to work OK in this case. While doing 
> this, I also refactored the handling of libz cflags and libs. They are 
> better set and exported from configure to be globally available in the 
> build.
> 
> We also get warnings when linking static libraries. These are easily 
> fixed by adding the -mmacosx-version-min= arguments on these command 
> lines just like we do for linking shared libraries and executables. I 
> solved this by setting ARFLAGS and actually use that variable.
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8196803
> 
> /Erik
> 


-- 
Best regards, Sergey.

From chris.plummer at oracle.com  Tue Feb  6 20:56:00 2018
From: chris.plummer at oracle.com (Chris Plummer)
Date: Tue, 6 Feb 2018 12:56:00 -0800
Subject: [OpenJDK 2D-Dev] Fwd: [PATCH] Fix compiler warnings with newer
 GCC 7.2.1
In-Reply-To: <73005887-dd65-f81e-6b86-7806d4813a69@oracle.com>
References: <b1965adc-2709-4241-85f9-1d0d022eca97@oracle.com>
 <4c5248f3-e78d-31ba-c892-fd7df1d027af@oracle.com>
 <5A75BD5F.5080309@oracle.com>
 <5eb1e208-bf8c-ec7e-2a75-3afc594e81d3@oracle.com>
 <73005887-dd65-f81e-6b86-7806d4813a69@oracle.com>
Message-ID: <8eefd33c-91bf-c2f6-69be-a41dd9cc5bda@oracle.com>

An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180206/5d68ab39/attachment.html>

From erik.joelsson at oracle.com  Tue Feb  6 21:03:58 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 6 Feb 2018 13:03:58 -0800
Subject: [OpenJDK 2D-Dev] RFR: JDK-8196803: Fix build warnings in jdk
 libraries with Xcode 9
In-Reply-To: <42c4a88f-0a22-b9b8-5549-964411c26df3@oracle.com>
References: <cb9aa034-2ca7-9539-11c2-5c6d94ddebf9@oracle.com>
 <42c4a88f-0a22-b9b8-5549-964411c26df3@oracle.com>
Message-ID: <c686fb2d-8d90-3315-4078-224286c9af8d@oracle.com>

Hello,

The 9 was just me being sloppy and thinking 9.x, I'm actually using 9.2. 
These are all the warnings I found in JDK libraries. There are 
additional ones in other parts of the build which have been dealt with 
in separate issues.

/Erik


On 2018-02-06 12:54, Sergey Bylokhov wrote:
> Hi, Erik.
> Why XCode 9 was selected? It seems that 9.2 is the latest one.
> 9.2 produces some additional warnings even after this fix.
>
> On 05/02/2018 14:54, Erik Joelsson wrote:
>> When building with Xcode 9, we get some warnings triggered in jdk 
>> libraries. This patch tries to fix them. See bug description for more 
>> details on each of them. In short the following things are addressed:
>>
>> In src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m, 
>> remove the check on MAC_OS_X_VERSION_MAX_ALLOWED. I don't think 
>> that's relevant. The source needs to compile against the headers that 
>> are present. This was touched on earlier in this thread: 
>> http://mail.openjdk.java.net/pipermail/build-dev/2017-July/019486.html 
>> and when going back, it's quite clear to me that the fix done there 
>> was incorrect.
>>
>> In src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c, 
>> we can't modify the source file itself, so here I've added a wrapper 
>> for zlib.h that rewrites the ZLIB_VERNUM macro to a version that 
>> matches what's available on the Macosx version we are building for. 
>> This type of override can be brittle but seems to work OK in this 
>> case. While doing this, I also refactored the handling of libz cflags 
>> and libs. They are better set and exported from configure to be 
>> globally available in the build.
>>
>> We also get warnings when linking static libraries. These are easily 
>> fixed by adding the -mmacosx-version-min= arguments on these command 
>> lines just like we do for linking shared libraries and executables. I 
>> solved this by setting ARFLAGS and actually use that variable.
>>
>> Webrev: http://cr.openjdk.java.net/~erikj/8196803/webrev.01/index.html
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8196803
>>
>> /Erik
>>
>
>


From adam.farley at uk.ibm.com  Wed Feb  7 16:38:29 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Wed, 7 Feb 2018 16:38:29 +0000
Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile
	jchuff.c
In-Reply-To: <fb45e541-939e-ca69-078e-944886738d79@oracle.com>
References: <OF8848EC5E.43B1571E-ON00258218.005E2FC4-80258218.00602FBE@notes.na.collabserv.com>
 <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com>
 <d01684d5-ed38-ed3d-29bb-ac83eb179b5c@oracle.com>
 <OFE12F9B33.1878F38D-ON0025821E.00491B34-8025821E.004B809B@notes.na.collabserv.com>
 <fa7bdcf7-3cbc-406b-684b-5483f946eb8e@oracle.com>
 <f8402e7d-a78d-c2b5-db98-f706487c5dcb@oracle.com>
 <bfba8731-d8ec-f3ea-b9c9-d324a841ee26@oracle.com>
 <OFD8411559.8853787A-ON00258227.003B5E29-80258227.003FCB62@notes.na.collabserv.com>
 <fb45e541-939e-ca69-078e-944886738d79@oracle.com>
Message-ID: <OFDC7A030E.429241CA-ON0025822D.005B4223-8025822D.005B6AD3@notes.na.collabserv.com>

 Re: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile 
jchuff.cErik Joelsson to: Adam Farley8 01/02/2018 17:06
Cc: build-dev, David Holmes, John Paul Adrian Glaubitz, Magnus Ihse Bursie
From: Erik Joelsson <erik.joelsson at oracle.com>
To: Adam Farley8 <adam.farley at uk.ibm.com>
Cc: build-dev <build-dev at openjdk.java.net>, David Holmes 
<david.holmes at oracle.com>, John Paul Adrian Glaubitz 
<glaubitz at physik.fu-berlin.de>, Magnus Ihse Bursie 
<magnus.ihse.bursie at oracle.com>
 

> Am I understanding this correctly that it's really not tied to a gcc 
version
> but a cpu architecture, so it's only really affecting s390x? 

I'm saying it is tied to a combination of CPU architecture and gcc 
version.
Any combination of the affected gcc versions (4.8.5, 5.4.0) and affected
platforms (zLinux, ppcle Linux) see this error.

x86 Linux is not affected, not are gcc versions equal to (or, I assume, 
later 
than) 7.2.1.

> Are you also saying that gcc 7.2.1 is also affected but with a different 

> message? I'm fine with disabling this warning conditional on s390x, no 
need 
> for specific gcc versions.

I was unclear. 7.2.1 fails my unit test with a different warning, but a 
build 
I ran proves that this warning doesn't fail the build.

That being said, the addition of this option to a 7.2.1 test didn't seem 
to 
break anything, so we should be fine to just stick 
"DISABLED_WARNINGS_gcc := clobbered array-bounds" into Awt2dLibraries.gmk. 


> This discussion has already taken more time than it really warrants. :)

Agreed. :)

> Regarding warning chasing. I agree that we it's not feasible to chase 
down every 
> warning in every version of GCC, or any other toolchain, but I also 
think that 
> for platforms/configurations where people are actively developing 
changes for 
> OpenJDK, it makes sense to try to keep it clean. This helps prevent new 
code from 
> introducing warnings. For the configurations Oracle use, we keep a 
strict -Werror 
> policy because we want the code to be clean. I'm fine with other users 
trying to 
> keep the same standards on their configurations, but knowing that it 
will be their 
> responsibility to keep up to date. I also think we need to be reasonably 
fine grained 
> in when we disable warnings. Specifying every affected version of a 
toolchain is too 
> much, but if there are specific well defined limits to where the 
disabling relevant, 
> then I think we should use them, within reason. This also helps with 
keeping track 
> of why a particular warning is disabled in a future attempt to fix them.

I agree with all of this. Well put. :)

> On the other hand, if you are just building OpenJDK to produce binaries, 
without 
> producing and up streaming new code changes, there really isn't much 
need for 
> making the effort of trying to keep things clean, and trying to do so 
will likely 
> just end up being more work than it's worth.
> /Erik

I'm building OpenJDK to test fixes and new features, which I will 
eventually contribute
to OpenJDK. I consider this to be one of those fixes. One fix at a time. 
:)

Given all of this, I ask for a volunteer to raise a bug so we can 
integrate this change 
into JDK8 (as it's still very popular), and JDK. 

10 would be great too, though I understand it's locked against all but the 
worst bugs.
9 is optional, as it's soon to be replaced by 10.

Best Regards

Adam Farley

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180207/0f795911/attachment.html>

From alexey.ushakov at jetbrains.com  Mon Feb 12 08:13:33 2018
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Mon, 12 Feb 2018 11:13:33 +0300
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
Message-ID: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>

Hello,

Here is the fix of the RepaintManager that adjust maximum double buffer size  after changes in the display environment. The fix is targeted for openjdk10 but the problem exists in previous releases. Please, have a look.

Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/ <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>

Best Regards,
Alexey 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180212/54225208/attachment.html>

From bourges.laurent at gmail.com  Mon Feb 12 09:14:35 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Mon, 12 Feb 2018 10:14:35 +0100
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
Message-ID: <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>

Hi,

I am not an official reviewer.

I just noted you left a stdout statement that should be removed or
commented out (trace).

You fix seems trivial

Laurent

Le 12 f?vr. 2018 09:14, "Alexey Ushakov" <alexey.ushakov at jetbrains.com> a
?crit :

> Hello,
>
> Here is the fix of the RepaintManager that adjust maximum double buffer
> size  after changes in the display environment. The fix is targeted for
> openjdk10 but the problem exists in previous releases. Please, have a look.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>
> Best Regards,
> Alexey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180212/6b387028/attachment.html>

From alexey.ushakov at jetbrains.com  Mon Feb 12 10:12:10 2018
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Mon, 12 Feb 2018 13:12:10 +0300
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
 <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
Message-ID: <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>

Thanks, for the catch, Laurent!

I forgot to remove my debug output that I used to detect the problem and verify the fix. It might be useful for reviewers though, so I left the original webrev  as is and added the new one.

Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/ <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/>

Best Regards,
Alexey

> On 12 Feb 2018, at 12:14, Laurent Bourg?s <bourges.laurent at gmail.com> wrote:
> 
> Hi,
> 
> I am not an official reviewer.
> 
> I just noted you left a stdout statement that should be removed or commented out (trace).
> 
> You fix seems trivial
> 
> Laurent
> 
> Le 12 f?vr. 2018 09:14, "Alexey Ushakov" <alexey.ushakov at jetbrains.com <mailto:alexey.ushakov at jetbrains.com>> a ?crit :
> Hello,
> 
> Here is the fix of the RepaintManager that adjust maximum double buffer size  after changes in the display environment. The fix is targeted for openjdk10 but the problem exists in previous releases. Please, have a look.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197499 <https://bugs.openjdk.java.net/browse/JDK-8197499>
> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/ <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>
> 
> Best Regards,
> Alexey 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180212/d6c563fe/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Feb 12 18:29:49 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 12 Feb 2018 10:29:49 -0800
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
 <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
 <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>
Message-ID: <0dfdba49-bc02-a9be-4ac1-603afd223050@oracle.com>

Hi, Alexey.
Two small comments:
  - It looks like that after the fix we will reset the value to "null" 
even if it was set by the user, for example the user may want to 
minimize the memory footprint if he knows that application limite the 
size of the windows.
  - setDoubleBufferMaximumSize includes clearImages() so it can be 
removed from displayChanged();

On 12/02/2018 02:12, Alexey Ushakov wrote:
> Thanks, for the catch, Laurent!
> 
> I forgot to remove my debug output that I used to detect the problem and 
> verify the fix. It might be useful for reviewers though, so I left the 
> original webrev ?as is and added the new one.
> 
> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/
> 
> Best Regards,
> Alexey
> 
>> On 12 Feb 2018, at 12:14, Laurent Bourg?s <bourges.laurent at gmail.com 
>> <mailto:bourges.laurent at gmail.com>> wrote:
>>
>> Hi,
>>
>> I am not an official reviewer.
>>
>> I just noted you left a stdout statement that should be removed or 
>> commented out (trace).
>>
>> You fix seems trivial
>>
>> Laurent
>>
>> Le?12 f?vr. 2018 09:14, "Alexey Ushakov" <alexey.ushakov at jetbrains.com 
>> <mailto:alexey.ushakov at jetbrains.com>> a ?crit?:
>>
>>     Hello,
>>
>>     Here is the fix of the RepaintManager that adjust maximum double
>>     buffer size ?after changes in the display environment. The fix is
>>     targeted for openjdk10 but the problem exists in previous
>>     releases. Please, have a look.
>>
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
>>     <https://bugs.openjdk.java.net/browse/JDK-8197499>
>>     Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>>     <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>
>>
>>     Best Regards,
>>     Alexey 
>>
> 


-- 
Best regards, Sergey.

From adam.farley at uk.ibm.com  Tue Feb 13 12:12:16 2018
From: adam.farley at uk.ibm.com (Adam Farley8)
Date: Tue, 13 Feb 2018 12:12:16 +0000
Subject: [OpenJDK 2D-Dev] RFR: Bug Pending: Build fails to compile
	jchuff.c
In-Reply-To: <OFDC7A030E.429241CA-ON0025822D.005B4223-8025822D.005B6A15@LocalDomain>
References: <OF8848EC5E.43B1571E-ON00258218.005E2FC4-80258218.00602FBE@notes.na.collabserv.com>
 <2db0bae0-9486-9656-ae83-27b6e28e190b@oracle.com>
 <d01684d5-ed38-ed3d-29bb-ac83eb179b5c@oracle.com>
 <OFE12F9B33.1878F38D-ON0025821E.00491B34-8025821E.004B809B@notes.na.collabserv.com>
 <fa7bdcf7-3cbc-406b-684b-5483f946eb8e@oracle.com>
 <f8402e7d-a78d-c2b5-db98-f706487c5dcb@oracle.com>
 <bfba8731-d8ec-f3ea-b9c9-d324a841ee26@oracle.com>
 <OFD8411559.8853787A-ON00258227.003B5E29-80258227.003FCB62@notes.na.collabserv.com>
 <fb45e541-939e-ca69-078e-944886738d79@oracle.com>
 <OFDC7A030E.429241CA-ON0025822D.005B4223-8025822D.005B6A15@LocalDomain>
Message-ID: <OF473E9C12.3749B960-ON80258233.00411F65-80258233.00430B2E@notes.na.collabserv.com>

-- Summary --

I ask for a committer to go into jdk/jdk and add one word to 
make/lib/Awt2dLibraries.gmk

We need to go to line 495 and add array-bounds into the list of disabled 
warnings.

So this:

DISABLED_WARNINGS_gcc := clobbered implicit-fallthrough 
shift-negative-value, \ 

becomes this:

DISABLED_WARNINGS_gcc := clobbered implicit-fallthrough 
shift-negative-value array-bounds, \

This fixes a build-breaking problem which occurs if you don't disable
errors-as-warnings on zLinux or Linux for ppcle.

P.S. Backporting this to jdk8 would be awesome, but the priority is 
jdk/jdk.




-- Conversation --

> Am I understanding this correctly that it's really not tied to a gcc 
version
> but a cpu architecture, so it's only really affecting s390x? 

I'm saying it is tied to a combination of CPU architecture and gcc 
version.
Any combination of the affected gcc versions (4.8.5, 5.4.0) and affected
platforms (zLinux, ppcle Linux) see this error.

x86 Linux is not affected, not are gcc versions equal to (or, I assume, 
later 
than) 7.2.1.

> Are you also saying that gcc 7.2.1 is also affected but with a different 

> message? I'm fine with disabling this warning conditional on s390x, no 
need 
> for specific gcc versions.

I was unclear. 7.2.1 fails my unit test with a different warning, but a 
build 
I ran proves that this warning doesn't fail the build.

That being said, the addition of this option to a 7.2.1 test didn't seem 
to 
break anything, so we should be fine to just stick 
"DISABLED_WARNINGS_gcc := clobbered array-bounds" into Awt2dLibraries.gmk. 


> This discussion has already taken more time than it really warrants. :)

Agreed. :)

> Regarding warning chasing. I agree that we it's not feasible to chase 
down every 
> warning in every version of GCC, or any other toolchain, but I also 
think that 
> for platforms/configurations where people are actively developing 
changes for 
> OpenJDK, it makes sense to try to keep it clean. This helps prevent new 
code from 
> introducing warnings. For the configurations Oracle use, we keep a 
strict -Werror 
> policy because we want the code to be clean. I'm fine with other users 
trying to 
> keep the same standards on their configurations, but knowing that it 
will be their 
> responsibility to keep up to date. I also think we need to be reasonably 
fine grained 
> in when we disable warnings. Specifying every affected version of a 
toolchain is too 
> much, but if there are specific well defined limits to where the 
disabling relevant, 
> then I think we should use them, within reason. This also helps with 
keeping track 
> of why a particular warning is disabled in a future attempt to fix them.

I agree with all of this. Well put. :)

> On the other hand, if you are just building OpenJDK to produce binaries, 
without 
> producing and up streaming new code changes, there really isn't much 
need for 
> making the effort of trying to keep things clean, and trying to do so 
will likely 
> just end up being more work than it's worth.
> /Erik

I'm building OpenJDK to test fixes and new features, which I will 
eventually contribute
to OpenJDK. I consider this to be one of those fixes. One fix at a time. 
:)

Given all of this, I ask for a volunteer to raise a bug so we can 
integrate this change 
into JDK8 (as it's still very popular), and JDK. 

10 would be great too, though I understand it's locked against all but the 
worst bugs.
9 is optional, as it's soon to be replaced by 10.

Best Regards

Adam Farley


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180213/16e6a8a0/attachment.html>

From alexey.ushakov at jetbrains.com  Tue Feb 13 13:19:44 2018
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Tue, 13 Feb 2018 16:19:44 +0300
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <0dfdba49-bc02-a9be-4ac1-603afd223050@oracle.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
 <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
 <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>
 <0dfdba49-bc02-a9be-4ac1-603afd223050@oracle.com>
Message-ID: <989457A0-9E2F-44F0-B8DC-210760BB92C1@jetbrains.com>

Hi Sergey,

Thanks for the comments. Here is updated version of the fix:

Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.02/ <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.02/>

Best Regards,
Alexey

> On 12 Feb 2018, at 21:29, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Alexey.
> Two small comments:
> - It looks like that after the fix we will reset the value to "null" even if it was set by the user, for example the user may want to minimize the memory footprint if he knows that application limite the size of the windows.
> - setDoubleBufferMaximumSize includes clearImages() so it can be removed from displayChanged();
> 
> On 12/02/2018 02:12, Alexey Ushakov wrote:
>> Thanks, for the catch, Laurent!
>> I forgot to remove my debug output that I used to detect the problem and verify the fix. It might be useful for reviewers though, so I left the original webrev  as is and added the new one.
>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/
>> Best Regards,
>> Alexey
>>> On 12 Feb 2018, at 12:14, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com>> wrote:
>>> 
>>> Hi,
>>> 
>>> I am not an official reviewer.
>>> 
>>> I just noted you left a stdout statement that should be removed or commented out (trace).
>>> 
>>> You fix seems trivial
>>> 
>>> Laurent
>>> 
>>> Le 12 f?vr. 2018 09:14, "Alexey Ushakov" <alexey.ushakov at jetbrains.com <mailto:alexey.ushakov at jetbrains.com>> a ?crit :
>>> 
>>>    Hello,
>>> 
>>>    Here is the fix of the RepaintManager that adjust maximum double
>>>    buffer size  after changes in the display environment. The fix is
>>>    targeted for openjdk10 but the problem exists in previous
>>>    releases. Please, have a look.
>>> 
>>>    Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
>>>    <https://bugs.openjdk.java.net/browse/JDK-8197499>
>>>    Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>>>    <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>
>>> 
>>>    Best Regards,
>>>    Alexey 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180213/2897792f/attachment.html>

From prahalad.kumar.narayanan at oracle.com  Tue Feb 13 18:15:23 2018
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Tue, 13 Feb 2018 10:15:23 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
	sun/java2d/OpenGL/DrawBufImgOp.java times out
Message-ID: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>

Hello Everyone

 

Good day to you.

 

Request your time in reviewing a minor change for a test bug

    [JDK-8196451]  sun/java2d/OpenGL/DrawBufImgOp.java times out

    https://bugs.openjdk.java.net/browse/JDK-8196451

 

Observation:

    . The bug reports a test case- DrawBufImgOp, failing with Timeout error on Win7 and OpenGL backend.

    . The issue wasn't reproducible despite multiple test runs on Win7 and Win10 machines. 

    . Hence OpenGL driver issues on the host machine is suspected to have resulted in this Timeout. 

 

Code change:

    . The code changes add a new keyword- "opengl" to TEST.ROOT and the respective test case.

    . Since D3D is the preferred back-end on Windows, this keyword will be helpful to filter OpenGL tests from execution in future.

    . Note: There are many bugs that are similar to the current one. But it's hard to propose a common fix as some of the test cases execute with multiple @run tags (one for every back-end).

 

Kindly review the change and suggest your views

Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/

 

Thank you for your time

Have a good day

 

Prahalad N.

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180213/3f89621f/attachment-0001.html>

From philip.race at oracle.com  Tue Feb 13 20:15:32 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 Feb 2018 12:15:32 -0800
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
 sun/java2d/OpenGL/DrawBufImgOp.java times out
In-Reply-To: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
References: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
Message-ID: <378a2094-f3b3-0650-a999-db666ed8dd8e@oracle.com>

This is fine.

-phil.

On 02/13/2018 10:15 AM, Prahalad Kumar Narayanan wrote:
>
> Hello Everyone
>
> Good day to you.
>
> Request your time in reviewing a minor change for a test bug
>
>     [JDK-8196451] sun/java2d/OpenGL/DrawBufImgOp.java times out
>
> https://bugs.openjdk.java.net/browse/JDK-8196451
>
> Observation:
>
>     . The bug reports a test case- DrawBufImgOp, failing with Timeout 
> error on Win7 and OpenGL backend.
>
>     . The issue wasn't reproducible despite multiple test runs on Win7 
> and Win10 machines.
>
>     . Hence OpenGL driver issues on the host machine is suspected to 
> have resulted in this Timeout.
>
> Code change:
>
>     . The code changes add a new keyword- ?opengl? to TEST.ROOT and 
> the respective test case.
>
>     . Since D3D is the preferred back-end on Windows, this keyword 
> will be helpful to filter OpenGL tests from execution in future.
>
>     . Note: There are many bugs that are similar to the current one. 
> But it?s hard to propose a common fix as some of the test cases 
> execute with multiple @run tags (one for every back-end).
>
> Kindly review the change and suggest your views
>
> Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/ 
> <http://cr.openjdk.java.net/%7Epnarayanan/8196451/webrev.00/>
>
> Thank you for your time
>
> Have a good day
>
> Prahalad N.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180213/32bbb7b8/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Feb 13 20:43:08 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Feb 2018 12:43:08 -0800
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
 sun/java2d/OpenGL/DrawBufImgOp.java times out
In-Reply-To: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
References: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
Message-ID: <d48e3d38-9459-79da-c40c-d6801e439aef@oracle.com>

Hi, Prahalad, Phil.
Maybe it is possible to add a log from jtr file to the bug report, 
usually it contains a stack trace on timeout. I am not sure that it is a 
good idea to update any tests without reproducing it, when we know that 
at least on one system it could be reproduced. The reasons maybe a slow 
virtual system and we need to update a timeout.


On 13/02/2018 10:15, Prahalad Kumar Narayanan wrote:
> Hello Everyone
> 
> Good day to you.
> 
> Request your time in reviewing a minor change for a test bug
> 
>  ??? [JDK-8196451]? sun/java2d/OpenGL/DrawBufImgOp.java times out
> 
> https://bugs.openjdk.java.net/browse/JDK-8196451
> 
> Observation:
> 
>  ??? . The bug reports a test case- DrawBufImgOp, failing with Timeout 
> error on Win7 and OpenGL backend.
> 
>  ??? . The issue wasn't reproducible despite multiple test runs on Win7 
> and Win10 machines.
> 
>  ????. Hence OpenGL driver issues on the host machine is suspected to 
> have resulted in this Timeout.
> 
> Code change:
> 
>  ??? . The code changes add a new keyword- ?opengl? to TEST.ROOT and the 
> respective test case.
> 
>  ??? . Since D3D is the preferred back-end on Windows, this keyword will 
> be helpful to filter OpenGL tests from execution in future.
> 
>  ??? . Note: There are many bugs that are similar to the current one. 
> But it?s hard to propose a common fix as some of the test cases execute 
> with multiple @run tags (one for every back-end).
> 
> Kindly review the change and suggest your views
> 
> Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/
> 
> Thank you for your time
> 
> Have a good day
> 
> Prahalad N.
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 13 21:44:46 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 Feb 2018 13:44:46 -0800
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
 sun/java2d/OpenGL/DrawBufImgOp.java times out
In-Reply-To: <d48e3d38-9459-79da-c40c-d6801e439aef@oracle.com>
References: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
 <d48e3d38-9459-79da-c40c-d6801e439aef@oracle.com>
Message-ID: <50fd8869-ba0c-6a9f-80a2-55bd731c5e45@oracle.com>

In this case I can say that it was nothing to do with being slow .. it 
is a driver bug.

-phil

On 02/13/2018 12:43 PM, Sergey Bylokhov wrote:
> Hi, Prahalad, Phil.
> Maybe it is possible to add a log from jtr file to the bug report, 
> usually it contains a stack trace on timeout. I am not sure that it is 
> a good idea to update any tests without reproducing it, when we know 
> that at least on one system it could be reproduced. The reasons maybe 
> a slow virtual system and we need to update a timeout.
>
>
> On 13/02/2018 10:15, Prahalad Kumar Narayanan wrote:
>> Hello Everyone
>>
>> Good day to you.
>>
>> Request your time in reviewing a minor change for a test bug
>>
>>      [JDK-8196451]  sun/java2d/OpenGL/DrawBufImgOp.java times out
>>
>> https://bugs.openjdk.java.net/browse/JDK-8196451
>>
>> Observation:
>>
>>      . The bug reports a test case- DrawBufImgOp, failing with 
>> Timeout error on Win7 and OpenGL backend.
>>
>>      . The issue wasn't reproducible despite multiple test runs on 
>> Win7 and Win10 machines.
>>
>>      . Hence OpenGL driver issues on the host machine is suspected to 
>> have resulted in this Timeout.
>>
>> Code change:
>>
>>      . The code changes add a new keyword- ?opengl? to TEST.ROOT and 
>> the respective test case.
>>
>>      . Since D3D is the preferred back-end on Windows, this keyword 
>> will be helpful to filter OpenGL tests from execution in future.
>>
>>      . Note: There are many bugs that are similar to the current one. 
>> But it?s hard to propose a common fix as some of the test cases 
>> execute with multiple @run tags (one for every back-end).
>>
>> Kindly review the change and suggest your views
>>
>> Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/
>>
>> Thank you for your time
>>
>> Have a good day
>>
>> Prahalad N.
>>
>
>


From Sergey.Bylokhov at oracle.com  Tue Feb 13 22:00:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Feb 2018 14:00:41 -0800
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <989457A0-9E2F-44F0-B8DC-210760BB92C1@jetbrains.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
 <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
 <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>
 <0dfdba49-bc02-a9be-4ac1-603afd223050@oracle.com>
 <989457A0-9E2F-44F0-B8DC-210760BB92C1@jetbrains.com>
Message-ID: <9f017ec1-4cf4-d934-c445-3151e3d098ba@oracle.com>

Looks fine.
Thank you.

On 13/02/2018 05:19, Alexey Ushakov wrote:
> Hi Sergey,
> 
> Thanks for the comments. Here is updated version of the fix:
> 
> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.02/
> 
> Best Regards,
> Alexey
> 
>> On 12 Feb 2018, at 21:29, Sergey Bylokhov <Sergey.Bylokhov at oracle.com 
>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Alexey.
>> Two small comments:
>> - It looks like that after the fix we will reset the value to "null" 
>> even if it was set by the user, for example the user may want to 
>> minimize the memory footprint if he knows that application limite the 
>> size of the windows.
>> - setDoubleBufferMaximumSize includes clearImages() so it can be 
>> removed from displayChanged();
>>
>> On 12/02/2018 02:12, Alexey Ushakov wrote:
>>> Thanks, for the catch, Laurent!
>>> I forgot to remove my debug output that I used to detect the problem 
>>> and verify the fix. It might be useful for reviewers though, so I 
>>> left the original webrev ?as is and added the new one.
>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/
>>> Best Regards,
>>> Alexey
>>>> On 12 Feb 2018, at 12:14, Laurent Bourg?s <bourges.laurent at gmail.com 
>>>> <mailto:bourges.laurent at gmail.com> 
>>>> <mailto:bourges.laurent at gmail.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am not an official reviewer.
>>>>
>>>> I just noted you left a stdout statement that should be removed or 
>>>> commented out (trace).
>>>>
>>>> You fix seems trivial
>>>>
>>>> Laurent
>>>>
>>>> Le?12 f?vr. 2018 09:14, "Alexey Ushakov" 
>>>> <alexey.ushakov at jetbrains.com <mailto:alexey.ushakov at jetbrains.com> 
>>>> <mailto:alexey.ushakov at jetbrains.com>> a ?crit?:
>>>>
>>>> ???Hello,
>>>>
>>>> ???Here is the fix of the RepaintManager that adjust maximum double
>>>> ???buffer size ?after changes in the display environment. The fix is
>>>> ???targeted for openjdk10 but the problem exists in previous
>>>> ???releases. Please, have a look.
>>>>
>>>> ???Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
>>>> ???<https://bugs.openjdk.java.net/browse/JDK-8197499>
>>>> ???Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>>>> ???<http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>
>>>>
>>>> ???Best Regards,
>>>> ???Alexey
>>
>>
>> -- 
>> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Feb 13 22:21:04 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 13 Feb 2018 14:21:04 -0800
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
 sun/java2d/OpenGL/DrawBufImgOp.java times out
In-Reply-To: <50fd8869-ba0c-6a9f-80a2-55bd731c5e45@oracle.com>
References: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
 <d48e3d38-9459-79da-c40c-d6801e439aef@oracle.com>
 <50fd8869-ba0c-6a9f-80a2-55bd731c5e45@oracle.com>
Message-ID: <540647db-5a25-f184-9873-4d68135ee01c@oracle.com>

On 13/02/2018 13:44, Phil Race wrote:
> In this case I can say that it was nothing to do with being slow .. it 
> is a driver bug.

Even if behavior depends from the driver does not mean that it is a bug 
in driver, we could do something wrong as well(since we have a bunch of 
artifacts in opengl pipeline on windows/linux). But if we do not want to 
invest time to investigate the reason of falure of this test on 
unsupported config(win+opengl) then I assume the same decision will be 
done for other possible failures as well.
I suggest to drop "-Dsun.java2d.opengl" option from our tests instead of 
excluding the tests by keyword, so the tests will cover default system 
pipeline(which is supported), and it will cover opengl on mac as well.
If it will be necessary to run the tests using some specific pipeline it 
will be possible to pass a parameter to jtreg to run all the tests using 
one pipeline.

> 
> -phil
> 
> On 02/13/2018 12:43 PM, Sergey Bylokhov wrote:
>> Hi, Prahalad, Phil.
>> Maybe it is possible to add a log from jtr file to the bug report, 
>> usually it contains a stack trace on timeout. I am not sure that it is 
>> a good idea to update any tests without reproducing it, when we know 
>> that at least on one system it could be reproduced. The reasons maybe 
>> a slow virtual system and we need to update a timeout.
>>
>>
>> On 13/02/2018 10:15, Prahalad Kumar Narayanan wrote:
>>> Hello Everyone
>>>
>>> Good day to you.
>>>
>>> Request your time in reviewing a minor change for a test bug
>>>
>>> ???? [JDK-8196451]? sun/java2d/OpenGL/DrawBufImgOp.java times out
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8196451
>>>
>>> Observation:
>>>
>>> ???? . The bug reports a test case- DrawBufImgOp, failing with 
>>> Timeout error on Win7 and OpenGL backend.
>>>
>>> ???? . The issue wasn't reproducible despite multiple test runs on 
>>> Win7 and Win10 machines.
>>>
>>> ???? . Hence OpenGL driver issues on the host machine is suspected to 
>>> have resulted in this Timeout.
>>>
>>> Code change:
>>>
>>> ???? . The code changes add a new keyword- ?opengl? to TEST.ROOT and 
>>> the respective test case.
>>>
>>> ???? . Since D3D is the preferred back-end on Windows, this keyword 
>>> will be helpful to filter OpenGL tests from execution in future.
>>>
>>> ???? . Note: There are many bugs that are similar to the current one. 
>>> But it?s hard to propose a common fix as some of the test cases 
>>> execute with multiple @run tags (one for every back-end).
>>>
>>> Kindly review the change and suggest your views
>>>
>>> Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/
>>>
>>> Thank you for your time
>>>
>>> Have a good day
>>>
>>> Prahalad N.
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 13 22:54:00 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 13 Feb 2018 14:54:00 -0800
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <9f017ec1-4cf4-d934-c445-3151e3d098ba@oracle.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
 <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
 <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>
 <0dfdba49-bc02-a9be-4ac1-603afd223050@oracle.com>
 <989457A0-9E2F-44F0-B8DC-210760BB92C1@jetbrains.com>
 <9f017ec1-4cf4-d934-c445-3151e3d098ba@oracle.com>
Message-ID: <0faa4210-ad25-e157-52ed-b51e360504d6@oracle.com>

+1 to the fix but two comments

1) I am not sure why this was sent to 2d-dev .. it is 100% Swing.

2) > The fix is targeted for openjdk10

Actually 11 now .. 10 is already in lock down as GA candidate builds are 
starting.

-phil.

On 02/13/2018 02:00 PM, Sergey Bylokhov wrote:
> Looks fine.
> Thank you.
>
> On 13/02/2018 05:19, Alexey Ushakov wrote:
>> Hi Sergey,
>>
>> Thanks for the comments. Here is updated version of the fix:
>>
>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.02/
>>
>> Best Regards,
>> Alexey
>>
>>> On 12 Feb 2018, at 21:29, Sergey Bylokhov 
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>
>>> Hi, Alexey.
>>> Two small comments:
>>> - It looks like that after the fix we will reset the value to "null" 
>>> even if it was set by the user, for example the user may want to 
>>> minimize the memory footprint if he knows that application limite 
>>> the size of the windows.
>>> - setDoubleBufferMaximumSize includes clearImages() so it can be 
>>> removed from displayChanged();
>>>
>>> On 12/02/2018 02:12, Alexey Ushakov wrote:
>>>> Thanks, for the catch, Laurent!
>>>> I forgot to remove my debug output that I used to detect the 
>>>> problem and verify the fix. It might be useful for reviewers 
>>>> though, so I left the original webrev  as is and added the new one.
>>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/
>>>> Best Regards,
>>>> Alexey
>>>>> On 12 Feb 2018, at 12:14, Laurent Bourg?s 
>>>>> <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com> 
>>>>> <mailto:bourges.laurent at gmail.com>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am not an official reviewer.
>>>>>
>>>>> I just noted you left a stdout statement that should be removed or 
>>>>> commented out (trace).
>>>>>
>>>>> You fix seems trivial
>>>>>
>>>>> Laurent
>>>>>
>>>>> Le 12 f?vr. 2018 09:14, "Alexey Ushakov" 
>>>>> <alexey.ushakov at jetbrains.com 
>>>>> <mailto:alexey.ushakov at jetbrains.com> 
>>>>> <mailto:alexey.ushakov at jetbrains.com>> a ?crit :
>>>>>
>>>>>    Hello,
>>>>>
>>>>>    Here is the fix of the RepaintManager that adjust maximum double
>>>>>    buffer size  after changes in the display environment. The fix is
>>>>>    targeted for openjdk10 but the problem exists in previous
>>>>>    releases. Please, have a look.
>>>>>
>>>>>    Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
>>>>>    <https://bugs.openjdk.java.net/browse/JDK-8197499>
>>>>>    Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>>>>>    <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>
>>>>>
>>>>>    Best Regards,
>>>>>    Alexey
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>


From alexey.ushakov at jetbrains.com  Wed Feb 14 05:50:52 2018
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Wed, 14 Feb 2018 08:50:52 +0300
Subject: [OpenJDK 2D-Dev] Review request for: JDK-8197499 RepaintManager
 does not increase double buffer after attaching a device with higher
 resolution
In-Reply-To: <0faa4210-ad25-e157-52ed-b51e360504d6@oracle.com>
References: <B1EC02E4-0039-4A52-AD6C-5892F4675FE5@jetbrains.com>
 <CAKjRUT7yW8JEQLpDkZ-VDUg9sYPgapu6eEtWuwpCxMXe0tdcVQ@mail.gmail.com>
 <25A96BAA-EA65-4D14-96B6-C9D76579B947@jetbrains.com>
 <0dfdba49-bc02-a9be-4ac1-603afd223050@oracle.com>
 <989457A0-9E2F-44F0-B8DC-210760BB92C1@jetbrains.com>
 <9f017ec1-4cf4-d934-c445-3151e3d098ba@oracle.com>
 <0faa4210-ad25-e157-52ed-b51e360504d6@oracle.com>
Message-ID: <F0BB3BFC-33E5-49C4-AC45-910B8C83BD62@jetbrains.com>

Thanks for the corrections, Phil. 

> 1) I am not sure why this was sent to 2d-dev .. it is 100% Swing.

Actually I also wasn?t completely sure that it is pure 2d issue but there was some graphics devices stuff involved so I decided to send it here.

> Actually 11 now .. 10 is already in lock down as GA candidate builds are starting.

No problem let?s target it for 11.

Best Regards,
Alexey

> On 14 Feb 2018, at 01:54, Phil Race <philip.race at oracle.com> wrote:
> 
> +1 to the fix but two comments
> 
> 1) I am not sure why this was sent to 2d-dev .. it is 100% Swing.
> 
> 2) > The fix is targeted for openjdk10
> 
> Actually 11 now .. 10 is already in lock down as GA candidate builds are starting.
> 
> -phil.
> 
> On 02/13/2018 02:00 PM, Sergey Bylokhov wrote:
>> Looks fine.
>> Thank you.
>> 
>> On 13/02/2018 05:19, Alexey Ushakov wrote:
>>> Hi Sergey,
>>> 
>>> Thanks for the comments. Here is updated version of the fix:
>>> 
>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.02/
>>> 
>>> Best Regards,
>>> Alexey
>>> 
>>>> On 12 Feb 2018, at 21:29, Sergey Bylokhov <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>> 
>>>> Hi, Alexey.
>>>> Two small comments:
>>>> - It looks like that after the fix we will reset the value to "null" even if it was set by the user, for example the user may want to minimize the memory footprint if he knows that application limite the size of the windows.
>>>> - setDoubleBufferMaximumSize includes clearImages() so it can be removed from displayChanged();
>>>> 
>>>> On 12/02/2018 02:12, Alexey Ushakov wrote:
>>>>> Thanks, for the catch, Laurent!
>>>>> I forgot to remove my debug output that I used to detect the problem and verify the fix. It might be useful for reviewers though, so I left the original webrev  as is and added the new one.
>>>>> Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.01/
>>>>> Best Regards,
>>>>> Alexey
>>>>>> On 12 Feb 2018, at 12:14, Laurent Bourg?s <bourges.laurent at gmail.com <mailto:bourges.laurent at gmail.com> <mailto:bourges.laurent at gmail.com>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I am not an official reviewer.
>>>>>> 
>>>>>> I just noted you left a stdout statement that should be removed or commented out (trace).
>>>>>> 
>>>>>> You fix seems trivial
>>>>>> 
>>>>>> Laurent
>>>>>> 
>>>>>> Le 12 f?vr. 2018 09:14, "Alexey Ushakov" <alexey.ushakov at jetbrains.com <mailto:alexey.ushakov at jetbrains.com> <mailto:alexey.ushakov at jetbrains.com>> a ?crit :
>>>>>> 
>>>>>>   Hello,
>>>>>> 
>>>>>>   Here is the fix of the RepaintManager that adjust maximum double
>>>>>>   buffer size  after changes in the display environment. The fix is
>>>>>>   targeted for openjdk10 but the problem exists in previous
>>>>>>   releases. Please, have a look.
>>>>>> 
>>>>>>   Bug: https://bugs.openjdk.java.net/browse/JDK-8197499
>>>>>>   <https://bugs.openjdk.java.net/browse/JDK-8197499>
>>>>>>   Webrev: http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/
>>>>>>   <http://cr.openjdk.java.net/~avu/JDK-8197499/webrev.00/>
>>>>>> 
>>>>>>   Best Regards,
>>>>>>   Alexey
>>>> 
>>>> 
>>>> -- 
>>>> Best regards, Sergey.
>>> 
>> 
>> 
> 


From prahalad.kumar.narayanan at oracle.com  Wed Feb 14 13:08:52 2018
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Wed, 14 Feb 2018 05:08:52 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
 sun/java2d/OpenGL/DrawBufImgOp.java times out
In-Reply-To: <540647db-5a25-f184-9873-4d68135ee01c@oracle.com>
References: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
 <d48e3d38-9459-79da-c40c-d6801e439aef@oracle.com>
 <50fd8869-ba0c-6a9f-80a2-55bd731c5e45@oracle.com>
 <540647db-5a25-f184-9873-4d68135ee01c@oracle.com>
Message-ID: <7fed72e6-9caa-4af3-940f-892a4a75ff83@default>

Hello Sergey

Thank you for your time in review & suggestions.

I understand both of your points- 
    . Need to examine cause of failure/ artifacts etc., and 
    . Suggestion to drop "-Dsun.java2d.opengl" from test cases. 

The intent of this fix and many similar fixes to come is to stabilize our test suite. So running OpenGL tests on un supported configurations can be avoided for now. Post the stabilization, we can inspect OpenGL failures/ artifacts where OpenGL isn't the default pipeline. 

Hence, we not only need a provision to configure our automated build and test systems to exclude OpenGL tests but also need a provision to execute tests whenever required in future. The keywords approach helps to address both. Hence this proposed fix.

Kindly let me know your views.

Thank you once again for your time
Have a good day

Prahalad N.


-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, February 14, 2018 3:51 AM
To: Phil Race; Prahalad Kumar Narayanan; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451] sun/java2d/OpenGL/DrawBufImgOp.java times out

On 13/02/2018 13:44, Phil Race wrote:
> In this case I can say that it was nothing to do with being slow .. it 
> is a driver bug.

Even if behavior depends from the driver does not mean that it is a bug in driver, we could do something wrong as well(since we have a bunch of artifacts in opengl pipeline on windows/linux). But if we do not want to invest time to investigate the reason of falure of this test on unsupported config(win+opengl) then I assume the same decision will be done for other possible failures as well.
I suggest to drop "-Dsun.java2d.opengl" option from our tests instead of excluding the tests by keyword, so the tests will cover default system pipeline(which is supported), and it will cover opengl on mac as well.
If it will be necessary to run the tests using some specific pipeline it will be possible to pass a parameter to jtreg to run all the tests using one pipeline.

> 
> -phil
> 
> On 02/13/2018 12:43 PM, Sergey Bylokhov wrote:
>> Hi, Prahalad, Phil.
>> Maybe it is possible to add a log from jtr file to the bug report, 
>> usually it contains a stack trace on timeout. I am not sure that it 
>> is a good idea to update any tests without reproducing it, when we 
>> know that at least on one system it could be reproduced. The reasons 
>> maybe a slow virtual system and we need to update a timeout.
>>
>>
>> On 13/02/2018 10:15, Prahalad Kumar Narayanan wrote:
>>> Hello Everyone
>>>
>>> Good day to you.
>>>
>>> Request your time in reviewing a minor change for a test bug
>>>
>>> ???? [JDK-8196451]? sun/java2d/OpenGL/DrawBufImgOp.java times out
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8196451
>>>
>>> Observation:
>>>
>>> ???? . The bug reports a test case- DrawBufImgOp, failing with 
>>> Timeout error on Win7 and OpenGL backend.
>>>
>>> ???? . The issue wasn't reproducible despite multiple test runs on
>>> Win7 and Win10 machines.
>>>
>>> ???? . Hence OpenGL driver issues on the host machine is suspected 
>>> to have resulted in this Timeout.
>>>
>>> Code change:
>>>
>>> ???? . The code changes add a new keyword- "opengl" to TEST.ROOT and 
>>> the respective test case.
>>>
>>> ???? . Since D3D is the preferred back-end on Windows, this keyword 
>>> will be helpful to filter OpenGL tests from execution in future.
>>>
>>> ???? . Note: There are many bugs that are similar to the current one. 
>>> But it's hard to propose a common fix as some of the test cases 
>>> execute with multiple @run tags (one for every back-end).
>>>
>>> Kindly review the change and suggest your views
>>>
>>> Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/
>>>
>>> Thank you for your time
>>>
>>> Have a good day
>>>
>>> Prahalad N.
>>>
>>
>>
> 


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Feb 14 14:17:41 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Feb 2018 06:17:41 -0800
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451]
 sun/java2d/OpenGL/DrawBufImgOp.java times out
In-Reply-To: <7fed72e6-9caa-4af3-940f-892a4a75ff83@default>
References: <2b7a7960-ed6e-4bee-b388-a04661e908d9@default>
 <d48e3d38-9459-79da-c40c-d6801e439aef@oracle.com>
 <50fd8869-ba0c-6a9f-80a2-55bd731c5e45@oracle.com>
 <540647db-5a25-f184-9873-4d68135ee01c@oracle.com>
 <7fed72e6-9caa-4af3-940f-892a4a75ff83@default>
Message-ID: <1bc94228-99bd-949c-4033-2a87330d6505@oracle.com>

On 14/02/2018 05:08, Prahalad Kumar Narayanan wrote:
> The intent of this fix and many similar fixes to come is to stabilize our test suite. So running OpenGL tests on un supported configurations can be avoided for now. Post the stabilization, we can inspect OpenGL failures/ artifacts where OpenGL isn't the default pipeline.

But for this purpose we can use ProblemList and postpone execution on 
windows until it will be fixed. But this case as well as adding of 
additional keyword has one limitation, the test will be excluded but it 
could be useful to run it using default pipeline.

To summarize: if we plan to fix it later then we can use ProblemList(it 
is possible to exclude the test per platform), if we did not plan to fix 
it in near future then we can drop an addition pipeline and cover a 
default one.
It does not mean that we should close related bugs, for example the bug 
for swing where the LAF is passed as an additional option to jtreg:
https://bugs.openjdk.java.net/browse/JDK-8068292
We could do the same thing for such bugs in java2d for non default piplines.

I am sure that even if we will drop this option we will not lose much, 
because only some small amount(~50) of tests use it, so to cover the 
opengl pipeline by all tests it is necessary to run the jtreg using 
-Dsun.java2d.opengl=true

> Hence, we not only need a provision to configure our automated build and test systems to exclude OpenGL tests but also need a provision to execute tests whenever required in future. The keywords approach helps to address both. Hence this proposed fix.
> 
> Kindly let me know your views.
> 
> Thank you once again for your time
> Have a good day
> 
> Prahalad N.
> 
> 
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Wednesday, February 14, 2018 3:51 AM
> To: Phil Race; Prahalad Kumar Narayanan; 2d-dev
> Subject: Re: [OpenJDK 2D-Dev] [11] RFR: [JDK-8196451] sun/java2d/OpenGL/DrawBufImgOp.java times out
> 
> On 13/02/2018 13:44, Phil Race wrote:
>> In this case I can say that it was nothing to do with being slow .. it
>> is a driver bug.
> 
> Even if behavior depends from the driver does not mean that it is a bug in driver, we could do something wrong as well(since we have a bunch of artifacts in opengl pipeline on windows/linux). But if we do not want to invest time to investigate the reason of falure of this test on unsupported config(win+opengl) then I assume the same decision will be done for other possible failures as well.
> I suggest to drop "-Dsun.java2d.opengl" option from our tests instead of excluding the tests by keyword, so the tests will cover default system pipeline(which is supported), and it will cover opengl on mac as well.
> If it will be necessary to run the tests using some specific pipeline it will be possible to pass a parameter to jtreg to run all the tests using one pipeline.
> 
>>
>> -phil
>>
>> On 02/13/2018 12:43 PM, Sergey Bylokhov wrote:
>>> Hi, Prahalad, Phil.
>>> Maybe it is possible to add a log from jtr file to the bug report,
>>> usually it contains a stack trace on timeout. I am not sure that it
>>> is a good idea to update any tests without reproducing it, when we
>>> know that at least on one system it could be reproduced. The reasons
>>> maybe a slow virtual system and we need to update a timeout.
>>>
>>>
>>> On 13/02/2018 10:15, Prahalad Kumar Narayanan wrote:
>>>> Hello Everyone
>>>>
>>>> Good day to you.
>>>>
>>>> Request your time in reviewing a minor change for a test bug
>>>>
>>>>  ???? [JDK-8196451]? sun/java2d/OpenGL/DrawBufImgOp.java times out
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8196451
>>>>
>>>> Observation:
>>>>
>>>>  ???? . The bug reports a test case- DrawBufImgOp, failing with
>>>> Timeout error on Win7 and OpenGL backend.
>>>>
>>>>  ???? . The issue wasn't reproducible despite multiple test runs on
>>>> Win7 and Win10 machines.
>>>>
>>>>  ???? . Hence OpenGL driver issues on the host machine is suspected
>>>> to have resulted in this Timeout.
>>>>
>>>> Code change:
>>>>
>>>>  ???? . The code changes add a new keyword- "opengl" to TEST.ROOT and
>>>> the respective test case.
>>>>
>>>>  ???? . Since D3D is the preferred back-end on Windows, this keyword
>>>> will be helpful to filter OpenGL tests from execution in future.
>>>>
>>>>  ???? . Note: There are many bugs that are similar to the current one.
>>>> But it's hard to propose a common fix as some of the test cases
>>>> execute with multiple @run tags (one for every back-end).
>>>>
>>>> Kindly review the change and suggest your views
>>>>
>>>> Link: http://cr.openjdk.java.net/~pnarayanan/8196451/webrev.00/
>>>>
>>>> Thank you for your time
>>>>
>>>> Have a good day
>>>>
>>>> Prahalad N.
>>>>
>>>
>>>
>>
> 
> 
> --
> Best regards, Sergey.
> 


-- 
Best regards, Sergey.

From bourges.laurent at gmail.com  Thu Feb 15 17:30:44 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Thu, 15 Feb 2018 18:30:44 +0100
Subject: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1
Message-ID: <CAKjRUT4oLfL+YWWah5rSXs68DR+h95K590GerN9YFaAv5=4qHg@mail.gmail.com>

Hi,

Please review this large patch providing Marlin 0.9.1 for JDK 11:

JBS: to be created asap
webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.0/

Changes:
- *ArrayCache: removed clean flag and usage of jdk.internal.UNSAFE.
allocateUninitializedArray()
- (D)Curve: added support for lines (curve type 4) + new methods x/y Points
to compute intersections on clip edges
- (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
clipping in Dasher that uses skipLen() to compute properly the dash phase &
state
- (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
fastXXXLen() to quickly estimate curve length from control points
      moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
determine t values corresponding to curve intersections with the clip edges
+ added subdivideLineAt() to subdivide line segments
- (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
enabled (2nd clipping is counter-productive) + initialize new path
simplifier if enabled (disabled by default) + log new settings
- (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
- (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
refactoring)
- (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter to
clip filled shapes overlapping clipping edges
            added CurveClipSplitter that subdivides curves (line, quad,
cubic) at clip intersections (+ small padding to avoid precision issues)
            added CurveBasicMonotonizer to monotonize curves (before in
Stroker) to make it on initial curve in Dasher (more efficient than for all
dashes)
- (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
too small segments (radial distance threshold)
- ClipShapeTest: improved test to use a small tolerance as clipped curves
(at clip edges) has minor impact on computed offsets for stroked shapes and
on dash positions: overall quality is improved as previously larger curves
had more accumulated error on either dashes or stroke offsets

Build & jtreg tests: OK

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180215/c319348e/attachment.html>

From andrea.aime at gmail.com  Mon Feb 19 11:52:07 2018
From: andrea.aime at gmail.com (Andrea Aime)
Date: Mon, 19 Feb 2018 12:52:07 +0100
Subject: [OpenJDK 2D-Dev] Who to contact about potential JAI licence change?
Message-ID: <CA+nxMTu8fNnFieokO8ZTZ6qRrENK72EtRRMRq9dAro_A4f+yOQ@mail.gmail.com>

Hi,
Java Advanced Imaging has been unsupported for a long time, but it's still
the best Java based
image processing library (at least for large imagery cases, the tiled
based, deferred computation
approach is something software in other languages is still copying today).

Its complete pluggability also makes it very easy to replace old buggy
operations with newer ones, which is
something done in open source projects like jai-ext:
https://github.com/geosolutions-it/jai-ext

However, its license is still a problem, it is not considered proper open
source.

Ideally all the Java portion would be useful, but in case that is a
problem, just getting the interfaces relicenced
would be of great help.
So, is there anyone we could talk to about JAI relicencing? If more than
one person/company needs to be
contacted I'm happy to reach out, just need to get some contacts.

Best regards
Andrea Aime
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180219/fd713db6/attachment.html>

From linuxhippy at gmail.com  Tue Feb 20 13:33:40 2018
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 20 Feb 2018 14:33:40 +0100
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when
 painting translucent colors on volatile images using XRender.
In-Reply-To: <b163cb1b-0883-aa5b-8e7e-5dffeb29baed@oracle.com>
References: <fa84e11b-4654-4dce-862b-726af8e349c8@default>
 <c8ecedda-50d7-c258-6e33-3b8d52db1bda@oracle.com>
 <b3945faa-541c-4b61-aead-9afe61ea3e0d@default>
 <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default>
 <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default>
 <85479031-dc5f-4d6f-b496-662b13604cd1@default>
 <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default>
 <CAFvQSYQEMxKYNgMQnEfZOcSKNSc2g=cQkmNkgsmYoBzTp2NA+Q@mail.gmail.com>
 <b163cb1b-0883-aa5b-8e7e-5dffeb29baed@oracle.com>
Message-ID: <CAFvQSYRjv4ZYswTTLqtv-hvq_oxYrj=wPxfSAJq=KhBQu2q9Mw@mail.gmail.com>

Hi,

>>> 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter
>>> based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts
>>> the color to pre-multiplied values.

Sorry for the dumb question, but what is the most recent 2d-dev repo,
which includes this change.
I have some significant performance enhancements for xrender regarding
MaskFill/Blit which I would like to re-base onto the lastest
"official" version.

I checked out the JDK and the JDK10 repo, but both did not contain this fix.

Thank you in advance & best regards, Clemens

From jayathirth.d.v at oracle.com  Tue Feb 20 13:39:57 2018
From: jayathirth.d.v at oracle.com (Jayathirth D V)
Date: Tue, 20 Feb 2018 05:39:57 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when
 painting translucent colors on volatile images using XRender.
In-Reply-To: <CAFvQSYRjv4ZYswTTLqtv-hvq_oxYrj=wPxfSAJq=KhBQu2q9Mw@mail.gmail.com>
References: <fa84e11b-4654-4dce-862b-726af8e349c8@default>
 <c8ecedda-50d7-c258-6e33-3b8d52db1bda@oracle.com>
 <b3945faa-541c-4b61-aead-9afe61ea3e0d@default>
 <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default>
 <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default>
 <85479031-dc5f-4d6f-b496-662b13604cd1@default>
 <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default>
 <CAFvQSYQEMxKYNgMQnEfZOcSKNSc2g=cQkmNkgsmYoBzTp2NA+Q@mail.gmail.com>
 <b163cb1b-0883-aa5b-8e7e-5dffeb29baed@oracle.com>
 <CAFvQSYRjv4ZYswTTLqtv-hvq_oxYrj=wPxfSAJq=KhBQu2q9Mw@mail.gmail.com>
Message-ID: <56c7c522-cc89-485e-b6ed-0c7c5ac018a8@default>

Hi Clemens,

Forked repo for all the latest client changes is : http://hg.openjdk.java.net/jdk/client 

Thanks,
Jay

-----Original Message-----
From: Clemens Eisserer [mailto:linuxhippy at gmail.com] 
Sent: Tuesday, February 20, 2018 7:04 PM
To: 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender.

Hi,

>>> 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter 
>>> based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and 
>>> converts the color to pre-multiplied values.

Sorry for the dumb question, but what is the most recent 2d-dev repo, which includes this change.
I have some significant performance enhancements for xrender regarding MaskFill/Blit which I would like to re-base onto the lastest "official" version.

I checked out the JDK and the JDK10 repo, but both did not contain this fix.

Thank you in advance & best regards, Clemens

From Sergey.Bylokhov at oracle.com  Tue Feb 20 15:10:14 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Feb 2018 07:10:14 -0800
Subject: [OpenJDK 2D-Dev] [11] Review Request: 8198333 ProblemList should be
 updated for headless mode
Message-ID: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>

Hello.
Please review update of the tests for jdk11.

The goal is to make our testing as stable as possible and exclude any 
unstable tests(I have started from the tests which may be run in the 
headless mode).

Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
Webrev can be found at: http://cr.openjdk.java.net/~serb/8198333/webrev.09

  - The ProblemList.txt is update, I have created a list of new bugs for 
any tests which fail at least once in a few iterations on a different 
systems.
  - "@key headful" was added to some tests which are noop in headless 
mode, they have some checks like:
     * Desktop.isDesktopSupported
     * Toolkit.getDefaultToolkit().getClass().getName().equals/
     * GraphicsEnvironment.isHeadlessInstance()
     * SystemTray.isSupported()
    ... etc. These checks are always false in headless mode.
  - "@key printer" was added to the tests which works in the headless 
mode, and tries to print something. Some of these tests are noop w/o 
printer.
  - "@run main/othervm" was added to a few tests which fails in agentvm 
mode. This mode is a default in mach5.
  - A few typos in the tests tags were fixed.

-- 
Best regards, Sergey.

From philip.race at oracle.com  Tue Feb 20 20:03:22 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Feb 2018 12:03:22 -0800
Subject: [OpenJDK 2D-Dev] [11] Review Request: 8198333 ProblemList
 should be updated for headless mode
In-Reply-To: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
Message-ID: <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>

+1

-phil

On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
> Hello.
> Please review update of the tests for jdk11.
>
> The goal is to make our testing as stable as possible and exclude any 
> unstable tests(I have started from the tests which may be run in the 
> headless mode).
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>
>  - The ProblemList.txt is update, I have created a list of new bugs 
> for any tests which fail at least once in a few iterations on a 
> different systems.
>  - "@key headful" was added to some tests which are noop in headless 
> mode, they have some checks like:
>     * Desktop.isDesktopSupported
>     * Toolkit.getDefaultToolkit().getClass().getName().equals/
>     * GraphicsEnvironment.isHeadlessInstance()
>     * SystemTray.isSupported()
>    ... etc. These checks are always false in headless mode.
>  - "@key printer" was added to the tests which works in the headless 
> mode, and tries to print something. Some of these tests are noop w/o 
> printer.
>  - "@run main/othervm" was added to a few tests which fails in agentvm 
> mode. This mode is a default in mach5.
>  - A few typos in the tests tags were fixed.
>


From linuxhippy at gmail.com  Tue Feb 20 20:24:35 2018
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 20 Feb 2018 21:24:35 +0100
Subject: [OpenJDK 2D-Dev] Proposal: improved AA tile upload for xrender
Message-ID: <CAFvQSYT85pg3U-BwzSTyp_A5156G2BtutpDa75sK4h3t-upOVw@mail.gmail.com>



From philip.race at oracle.com  Tue Feb 20 21:13:02 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Feb 2018 13:13:02 -0800
Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when
 painting translucent colors on volatile images using XRender.
In-Reply-To: <56c7c522-cc89-485e-b6ed-0c7c5ac018a8@default>
References: <fa84e11b-4654-4dce-862b-726af8e349c8@default>
 <c8ecedda-50d7-c258-6e33-3b8d52db1bda@oracle.com>
 <b3945faa-541c-4b61-aead-9afe61ea3e0d@default>
 <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default>
 <78bf6d21-bc93-4c79-8f52-ecb690c5381a@default>
 <85479031-dc5f-4d6f-b496-662b13604cd1@default>
 <2f2b14a1-eecb-4477-bc17-1ae93e392d88@default>
 <CAFvQSYQEMxKYNgMQnEfZOcSKNSc2g=cQkmNkgsmYoBzTp2NA+Q@mail.gmail.com>
 <b163cb1b-0883-aa5b-8e7e-5dffeb29baed@oracle.com>
 <CAFvQSYRjv4ZYswTTLqtv-hvq_oxYrj=wPxfSAJq=KhBQu2q9Mw@mail.gmail.com>
 <56c7c522-cc89-485e-b6ed-0c7c5ac018a8@default>
Message-ID: <d0ecdd44-2fe1-cf2d-d219-7bf6229793c4@oracle.com>

Clemens,

What Jay said .. going forward the repos with a number in them are now 
all stabilisation repos
to prepare for a release. So it won't be in JDK10 and there are very few 
forests so not 2d specific one.
Just one for all the client code.

I am not sure what you meant by "JDK" repo .. it definitely is also 
pushed into
the "master" as welll .. aka

http://hg.openjdk.java.net/jdk/jdk


See http://hg.openjdk.java.net/jdk/jdk/rev/e4b03365ddbf

But you should work in  http://hg.openjdk.java.net/jdk/client

-phil.

On 02/20/2018 05:39 AM, Jayathirth D V wrote:
> Hi Clemens,
>
> Forked repo for all the latest client changes is : http://hg.openjdk.java.net/jdk/client
>
> Thanks,
> Jay
>
> -----Original Message-----
> From: Clemens Eisserer [mailto:linuxhippy at gmail.com]
> Sent: Tuesday, February 20, 2018 7:04 PM
> To: 2d-dev
> Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender.
>
> Hi,
>
>>>> 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter
>>>> based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and
>>>> converts the color to pre-multiplied values.
> Sorry for the dumb question, but what is the most recent 2d-dev repo, which includes this change.
> I have some significant performance enhancements for xrender regarding MaskFill/Blit which I would like to re-base onto the lastest "official" version.
>
> I checked out the JDK and the JDK10 repo, but both did not contain this fix.
>
> Thank you in advance & best regards, Clemens


From philip.race at oracle.com  Tue Feb 20 21:24:18 2018
From: philip.race at oracle.com (Phil Race)
Date: Tue, 20 Feb 2018 13:24:18 -0800
Subject: [OpenJDK 2D-Dev] Who to contact about potential JAI licence
 change?
In-Reply-To: <CA+nxMTu8fNnFieokO8ZTZ6qRrENK72EtRRMRq9dAro_A4f+yOQ@mail.gmail.com>
References: <CA+nxMTu8fNnFieokO8ZTZ6qRrENK72EtRRMRq9dAro_A4f+yOQ@mail.gmail.com>
Message-ID: <dd551c84-3111-8966-3e4a-21fdc7d72684@oracle.com>

Hi Andrea,

 From where are you downloading the JAI source these days ?
I assume GPL of some flavour would satisfy being a "proper" open source 
license.
I will pass this request up the chain to see if there is any interest in 
doing it, but can make no promises.

-phil.

On 02/19/2018 03:52 AM, Andrea Aime wrote:
> Hi,
> Java Advanced Imaging has been unsupported for a long time, but it's 
> still the best Java based
> image processing library (at least for large imagery cases, the tiled 
> based, deferred computation
> approach is something software in other languages is still copying today).
>
> Its complete pluggability also makes it very easy to replace old buggy 
> operations with newer ones, which is
> something done in open source projects like jai-ext: 
> https://github.com/geosolutions-it/jai-ext
>
> However, its license is still a problem, it is not considered proper 
> open source.
>
> Ideally all the Java portion would be useful, but in case that is a 
> problem, just getting the interfaces relicenced
> would be of great help.
> So, is there anyone we could talk to about JAI relicencing? If more 
> than one person/company needs to be
> contacted I'm happy to reach out, just need to get some contacts.
>
> Best regards
> Andrea Aime
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180220/10866903/attachment-0001.html>

From prasanta.sadhukhan at oracle.com  Wed Feb 21 13:58:02 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Feb 2018 19:28:02 +0530
Subject: [OpenJDK 2D-Dev] [11] Review Request: 8198333 ProblemList
 should be updated for headless mode
In-Reply-To: <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
Message-ID: <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>

Couple of points.

Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be run 
only on solaris/linux as it tests

if (!isXAWT){
   77             System.out.println(" this is XAWT-only test. ");
   78             return;
   79         }

java/awt/Toolkit/RealSync/Test.java has
System.exit(1);

Should we not remove that as it might hamper jtreg run?

I also think that this bugid needs to be added to all updated tests.

Regards
Prasanta

On 2/21/2018 1:33 AM, Phil Race wrote:
> +1
>
> -phil
>
> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>> Hello.
>> Please review update of the tests for jdk11.
>>
>> The goal is to make our testing as stable as possible and exclude any 
>> unstable tests(I have started from the tests which may be run in the 
>> headless mode).
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>> Webrev can be found at: 
>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>
>> ?- The ProblemList.txt is update, I have created a list of new bugs 
>> for any tests which fail at least once in a few iterations on a 
>> different systems.
>> ?- "@key headful" was added to some tests which are noop in headless 
>> mode, they have some checks like:
>> ??? * Desktop.isDesktopSupported
>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>> ??? * GraphicsEnvironment.isHeadlessInstance()
>> ??? * SystemTray.isSupported()
>> ?? ... etc. These checks are always false in headless mode.
>> ?- "@key printer" was added to the tests which works in the headless 
>> mode, and tries to print something. Some of these tests are noop w/o 
>> printer.
>> ?- "@run main/othervm" was added to a few tests which fails in 
>> agentvm mode. This mode is a default in mach5.
>> ?- A few typos in the tests tags were fixed.
>>
>


From prasanta.sadhukhan at oracle.com  Wed Feb 21 15:03:51 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Feb 2018 20:33:51 +0530
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
Message-ID: <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>

Also, these test should have @requires os.family too

/java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only

if (!osName.startsWith("mac")) {
   42             return;
   43         }

javax/print/PrintServiceLookup/CountPrintServices.java for linux only
if (!os.equals("linux")) {
   44         System.out.println("Linux specific test. No need to continue");
   45         return;
   46     }

Regards
Prasanta

On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
> Couple of points.
>
> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
> run only on solaris/linux as it tests
>
> if (!isXAWT){
> ? 77???????????? System.out.println(" this is XAWT-only test. ");
> ? 78???????????? return;
> ? 79???????? }
>
> java/awt/Toolkit/RealSync/Test.java has
> System.exit(1);
>
> Should we not remove that as it might hamper jtreg run?
>
> I also think that this bugid needs to be added to all updated tests.
>
> Regards
> Prasanta
>
> On 2/21/2018 1:33 AM, Phil Race wrote:
>> +1
>>
>> -phil
>>
>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>> Hello.
>>> Please review update of the tests for jdk11.
>>>
>>> The goal is to make our testing as stable as possible and exclude 
>>> any unstable tests(I have started from the tests which may be run in 
>>> the headless mode).
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>> Webrev can be found at: 
>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>
>>> ?- The ProblemList.txt is update, I have created a list of new bugs 
>>> for any tests which fail at least once in a few iterations on a 
>>> different systems.
>>> ?- "@key headful" was added to some tests which are noop in headless 
>>> mode, they have some checks like:
>>> ??? * Desktop.isDesktopSupported
>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>> ??? * SystemTray.isSupported()
>>> ?? ... etc. These checks are always false in headless mode.
>>> ?- "@key printer" was added to the tests which works in the headless 
>>> mode, and tries to print something. Some of these tests are noop w/o 
>>> printer.
>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>> agentvm mode. This mode is a default in mach5.
>>> ?- A few typos in the tests tags were fixed.
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Wed Feb 21 15:45:44 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 07:45:44 -0800
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
Message-ID: <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>

Hi, Prasanta.
I have updated the tests mentioned in your previous email:
http://cr.openjdk.java.net/~serb/8198333/webrev.10

> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
> 
> if (!osName.startsWith("mac")) {
>  ? 42???????????? return;
>  ? 43???????? }

I am not sure it has mac specific code, I'll reevaluate this test in 
JDK-8198406.


> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
> if (!os.equals("linux")) {
>  ? 44???????? System.out.println("Linux specific test. No need to 
> continue");
>  ? 45???????? return;
>  ? 46???? }

I guess this one could be run on mac as well, but it should be double 
checked.

Both tests have headful or printer keywords and already excluded in the 
headless mode, which is subject of the fix.

> 
> Regards
> Prasanta
> 
> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>> Couple of points.
>>
>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>> run only on solaris/linux as it tests
>>
>> if (!isXAWT){
>> ? 77???????????? System.out.println(" this is XAWT-only test. ");
>> ? 78???????????? return;
>> ? 79???????? }
>>
>> java/awt/Toolkit/RealSync/Test.java has
>> System.exit(1);
>>
>> Should we not remove that as it might hamper jtreg run?
>>
>> I also think that this bugid needs to be added to all updated tests.
>>
>> Regards
>> Prasanta
>>
>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>> +1
>>>
>>> -phil
>>>
>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>> Hello.
>>>> Please review update of the tests for jdk11.
>>>>
>>>> The goal is to make our testing as stable as possible and exclude 
>>>> any unstable tests(I have started from the tests which may be run in 
>>>> the headless mode).
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>> Webrev can be found at: 
>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>
>>>> ?- The ProblemList.txt is update, I have created a list of new bugs 
>>>> for any tests which fail at least once in a few iterations on a 
>>>> different systems.
>>>> ?- "@key headful" was added to some tests which are noop in headless 
>>>> mode, they have some checks like:
>>>> ??? * Desktop.isDesktopSupported
>>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>>> ??? * SystemTray.isSupported()
>>>> ?? ... etc. These checks are always false in headless mode.
>>>> ?- "@key printer" was added to the tests which works in the headless 
>>>> mode, and tries to print something. Some of these tests are noop w/o 
>>>> printer.
>>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>>> agentvm mode. This mode is a default in mach5.
>>>> ?- A few typos in the tests tags were fixed.
>>>>
>>>
>>
> 


-- 
Best regards, Sergey.

From prasanta.sadhukhan at oracle.com  Wed Feb 21 15:49:17 2018
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 21 Feb 2018 21:19:17 +0530
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
Message-ID: <e7df679e-abd2-7ef1-e5b3-7df66eadfd4c@oracle.com>

looks ok. Only thing is the tests do not have the current bugid appended.

Regards
Prasanta
On 2/21/2018 9:15 PM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> I have updated the tests mentioned in your previous email:
> http://cr.openjdk.java.net/~serb/8198333/webrev.10
>
>> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
>>
>> if (!osName.startsWith("mac")) {
>> ?? 42???????????? return;
>> ?? 43???????? }
>
> I am not sure it has mac specific code, I'll reevaluate this test in 
> JDK-8198406.
>
>
>> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
>> if (!os.equals("linux")) {
>> ?? 44???????? System.out.println("Linux specific test. No need to 
>> continue");
>> ?? 45???????? return;
>> ?? 46???? }
>
> I guess this one could be run on mac as well, but it should be double 
> checked.
>
> Both tests have headful or printer keywords and already excluded in 
> the headless mode, which is subject of the fix.
>
>>
>> Regards
>> Prasanta
>>
>> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>>> Couple of points.
>>>
>>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>>> run only on solaris/linux as it tests
>>>
>>> if (!isXAWT){
>>> ? 77???????????? System.out.println(" this is XAWT-only test. ");
>>> ? 78???????????? return;
>>> ? 79???????? }
>>>
>>> java/awt/Toolkit/RealSync/Test.java has
>>> System.exit(1);
>>>
>>> Should we not remove that as it might hamper jtreg run?
>>>
>>> I also think that this bugid needs to be added to all updated tests.
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>>> +1
>>>>
>>>> -phil
>>>>
>>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review update of the tests for jdk11.
>>>>>
>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>> any unstable tests(I have started from the tests which may be run 
>>>>> in the headless mode).
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>>
>>>>> ?- The ProblemList.txt is update, I have created a list of new 
>>>>> bugs for any tests which fail at least once in a few iterations on 
>>>>> a different systems.
>>>>> ?- "@key headful" was added to some tests which are noop in 
>>>>> headless mode, they have some checks like:
>>>>> ??? * Desktop.isDesktopSupported
>>>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>>>> ??? * SystemTray.isSupported()
>>>>> ?? ... etc. These checks are always false in headless mode.
>>>>> ?- "@key printer" was added to the tests which works in the 
>>>>> headless mode, and tries to print something. Some of these tests 
>>>>> are noop w/o printer.
>>>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>>>> agentvm mode. This mode is a default in mach5.
>>>>> ?- A few typos in the tests tags were fixed.
>>>>>
>>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Wed Feb 21 16:04:44 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 08:04:44 -0800
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <e7df679e-abd2-7ef1-e5b3-7df66eadfd4c@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
 <e7df679e-abd2-7ef1-e5b3-7df66eadfd4c@oracle.com>
Message-ID: <f9d47afa-dddd-4f82-872e-9212cd21de06@oracle.com>

I am not sure that it is useful to add a bugid when the test is moved or 
some tags are updated or some small bugs fixed in the test.

The @bug tag contains a bugid for which it was written or an bugid which 
was found by this test later.
It can contain the bugid of bugfix in the test if the fix will rewrite 
the test completely or add some new steps to check(But it likely will be 
an RFE)

On 21/02/2018 07:49, Prasanta Sadhukhan wrote:
> looks ok. Only thing is the tests do not have the current bugid appended.
> 
> Regards
> Prasanta
> On 2/21/2018 9:15 PM, Sergey Bylokhov wrote:
>> Hi, Prasanta.
>> I have updated the tests mentioned in your previous email:
>> http://cr.openjdk.java.net/~serb/8198333/webrev.10
>>
>>> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
>>>
>>> if (!osName.startsWith("mac")) {
>>> ?? 42???????????? return;
>>> ?? 43???????? }
>>
>> I am not sure it has mac specific code, I'll reevaluate this test in 
>> JDK-8198406.
>>
>>
>>> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
>>> if (!os.equals("linux")) {
>>> ?? 44???????? System.out.println("Linux specific test. No need to 
>>> continue");
>>> ?? 45???????? return;
>>> ?? 46???? }
>>
>> I guess this one could be run on mac as well, but it should be double 
>> checked.
>>
>> Both tests have headful or printer keywords and already excluded in 
>> the headless mode, which is subject of the fix.
>>
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>>>> Couple of points.
>>>>
>>>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>>>> run only on solaris/linux as it tests
>>>>
>>>> if (!isXAWT){
>>>> ? 77???????????? System.out.println(" this is XAWT-only test. ");
>>>> ? 78???????????? return;
>>>> ? 79???????? }
>>>>
>>>> java/awt/Toolkit/RealSync/Test.java has
>>>> System.exit(1);
>>>>
>>>> Should we not remove that as it might hamper jtreg run?
>>>>
>>>> I also think that this bugid needs to be added to all updated tests.
>>>>
>>>> Regards
>>>> Prasanta
>>>>
>>>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>>>> +1
>>>>>
>>>>> -phil
>>>>>
>>>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>>>> Hello.
>>>>>> Please review update of the tests for jdk11.
>>>>>>
>>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>>> any unstable tests(I have started from the tests which may be run 
>>>>>> in the headless mode).
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>>>> Webrev can be found at: 
>>>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>>>
>>>>>> ?- The ProblemList.txt is update, I have created a list of new 
>>>>>> bugs for any tests which fail at least once in a few iterations on 
>>>>>> a different systems.
>>>>>> ?- "@key headful" was added to some tests which are noop in 
>>>>>> headless mode, they have some checks like:
>>>>>> ??? * Desktop.isDesktopSupported
>>>>>> ??? * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>>>> ??? * GraphicsEnvironment.isHeadlessInstance()
>>>>>> ??? * SystemTray.isSupported()
>>>>>> ?? ... etc. These checks are always false in headless mode.
>>>>>> ?- "@key printer" was added to the tests which works in the 
>>>>>> headless mode, and tries to print something. Some of these tests 
>>>>>> are noop w/o printer.
>>>>>> ?- "@run main/othervm" was added to a few tests which fails in 
>>>>>> agentvm mode. This mode is a default in mach5.
>>>>>> ?- A few typos in the tests tags were fixed.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
> 


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Feb 21 16:49:39 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 21 Feb 2018 08:49:39 -0800
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
Message-ID: <5A8DA323.5000907@oracle.com>



On 2/21/18, 7:45 AM, Sergey Bylokhov wrote:
> Hi, Prasanta.
> I have updated the tests mentioned in your previous email:
> http://cr.openjdk.java.net/~serb/8198333/webrev.10
>
>> /java/awt/font/TextLayout/TestAATMorxFont.java should be for mac only
>>
>> if (!osName.startsWith("mac")) {
>>    42             return;
>>    43         }
>
> I am not sure it has mac specific code, I'll reevaluate this test in 
> JDK-8198406.

This is mac-specific. It looks for specific fonts by name that exist 
only on MacOS.
And moreover the table handling in the implementation is relevant only 
for Apple AAT fonts ..
which you won't find anywhere else.
The one thing about this test that could change is that it doesn't need 
to create a Frame to
test this code -  drawing to a BI would suffice .. so it does not have 
to be headful with a few changes.

-phil.
>
>
>> javax/print/PrintServiceLookup/CountPrintServices.java for linux only
>> if (!os.equals("linux")) {
>>    44         System.out.println("Linux specific test. No need to 
>> continue");
>>    45         return;
>>    46     }
>
> I guess this one could be run on mac as well, but it should be double 
> checked.
>
> Both tests have headful or printer keywords and already excluded in 
> the headless mode, which is subject of the fix.
>
>>
>> Regards
>> Prasanta
>>
>> On 2/21/2018 7:28 PM, Prasanta Sadhukhan wrote:
>>> Couple of points.
>>>
>>> Shouldn't java/awt/List/SetBackgroundTest/SetBackgroundTest.java be 
>>> run only on solaris/linux as it tests
>>>
>>> if (!isXAWT){
>>>   77             System.out.println(" this is XAWT-only test. ");
>>>   78             return;
>>>   79         }
>>>
>>> java/awt/Toolkit/RealSync/Test.java has
>>> System.exit(1);
>>>
>>> Should we not remove that as it might hamper jtreg run?
>>>
>>> I also think that this bugid needs to be added to all updated tests.
>>>
>>> Regards
>>> Prasanta
>>>
>>> On 2/21/2018 1:33 AM, Phil Race wrote:
>>>> +1
>>>>
>>>> -phil
>>>>
>>>> On 02/20/2018 07:10 AM, Sergey Bylokhov wrote:
>>>>> Hello.
>>>>> Please review update of the tests for jdk11.
>>>>>
>>>>> The goal is to make our testing as stable as possible and exclude 
>>>>> any unstable tests(I have started from the tests which may be run 
>>>>> in the headless mode).
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8198333
>>>>> Webrev can be found at: 
>>>>> http://cr.openjdk.java.net/~serb/8198333/webrev.09
>>>>>
>>>>>  - The ProblemList.txt is update, I have created a list of new 
>>>>> bugs for any tests which fail at least once in a few iterations on 
>>>>> a different systems.
>>>>>  - "@key headful" was added to some tests which are noop in 
>>>>> headless mode, they have some checks like:
>>>>>     * Desktop.isDesktopSupported
>>>>>     * Toolkit.getDefaultToolkit().getClass().getName().equals/
>>>>>     * GraphicsEnvironment.isHeadlessInstance()
>>>>>     * SystemTray.isSupported()
>>>>>    ... etc. These checks are always false in headless mode.
>>>>>  - "@key printer" was added to the tests which works in the 
>>>>> headless mode, and tries to print something. Some of these tests 
>>>>> are noop w/o printer.
>>>>>  - "@run main/othervm" was added to a few tests which fails in 
>>>>> agentvm mode. This mode is a default in mach5.
>>>>>  - A few typos in the tests tags were fixed.
>>>>>
>>>>
>>>
>>
>
>

From Sergey.Bylokhov at oracle.com  Wed Feb 21 17:34:04 2018
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 21 Feb 2018 09:34:04 -0800
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <5A8DA323.5000907@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
 <5A8DA323.5000907@oracle.com>
Message-ID: <41e5a424-9cb3-95f9-9c29-9139fd8adfbc@oracle.com>

On 21/02/2018 08:49, Philip Race wrote:
>> I am not sure it has mac specific code, I'll reevaluate this test in 
>> JDK-8198406.
> 
> This is mac-specific. It looks for specific fonts by name that exist 
> only on MacOS.
> And moreover the table handling in the implementation is relevant only 
> for Apple AAT fonts ..
> which you won't find anywhere else.
> The one thing about this test that could change is that it doesn't need 
> to create a Frame to
> test this code -? drawing to a BI would suffice .. so it does not have 
> to be headful with a few changes.

I would not like to mix the test changes and updating the problem list. 
I have filed a separate bugs for each test which should be 
updated/reworked/fixed.


-- 
Best regards, Sergey.

From philip.race at oracle.com  Wed Feb 21 17:35:36 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 21 Feb 2018 09:35:36 -0800
Subject: [OpenJDK 2D-Dev] <Swing Dev> [11] Review Request: 8198333
 ProblemList should be updated for headless mode
In-Reply-To: <41e5a424-9cb3-95f9-9c29-9139fd8adfbc@oracle.com>
References: <e3bb883b-8f51-bcb3-aba8-39a8738a4dfc@oracle.com>
 <f1da6bf5-f9a8-8778-355a-faa89d0aa8c1@oracle.com>
 <5d3ad15c-47c2-a9f7-1f70-32fc5b58917d@oracle.com>
 <cd103841-8cdc-0430-7c58-63520f296b1e@oracle.com>
 <4ee66702-8494-dbe5-7e42-a334a8eef8e1@oracle.com>
 <5A8DA323.5000907@oracle.com>
 <41e5a424-9cb3-95f9-9c29-9139fd8adfbc@oracle.com>
Message-ID: <5A8DADE8.8010104@oracle.com>

That is fine.

-phil.

On 2/21/18, 9:34 AM, Sergey Bylokhov wrote:
> On 21/02/2018 08:49, Philip Race wrote:
>>> I am not sure it has mac specific code, I'll reevaluate this test in 
>>> JDK-8198406.
>>
>> This is mac-specific. It looks for specific fonts by name that exist 
>> only on MacOS.
>> And moreover the table handling in the implementation is relevant 
>> only for Apple AAT fonts ..
>> which you won't find anywhere else.
>> The one thing about this test that could change is that it doesn't 
>> need to create a Frame to
>> test this code -  drawing to a BI would suffice .. so it does not 
>> have to be headful with a few changes.
>
> I would not like to mix the test changes and updating the problem 
> list. I have filed a separate bugs for each test which should be 
> updated/reworked/fixed.
>
>

From bourges.laurent at gmail.com  Wed Feb 21 20:14:17 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Wed, 21 Feb 2018 21:14:17 +0100
Subject: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1
In-Reply-To: <CAKjRUT4oLfL+YWWah5rSXs68DR+h95K590GerN9YFaAv5=4qHg@mail.gmail.com>
References: <CAKjRUT4oLfL+YWWah5rSXs68DR+h95K590GerN9YFaAv5=4qHg@mail.gmail.com>
Message-ID: <CAKjRUT5NdFuUWsUN9_=D45qQ=KxWUdD3fBFgtDSRJxdCcMgFdQ@mail.gmail.com>

Phil,
Will you have some time soon to have a look ?

It fixes dashing performance definitively and dash error accumulation too.

Laurent

Le 15 f?vr. 2018 6:30 PM, "Laurent Bourg?s" <bourges.laurent at gmail.com> a
?crit :

> Hi,
>
> Please review this large patch providing Marlin 0.9.1 for JDK 11:
>
> JBS: to be created asap
> webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-091.0/
>
> Changes:
> - *ArrayCache: removed clean flag and usage of
> jdk.internal.UNSAFE.allocateUninitializedArray()
> - (D)Curve: added support for lines (curve type 4) + new methods x/y
> Points to compute intersections on clip edges
> - (D)Dasher: use new CurveBasicMonotonizer & CurveClipSplitter to perform
> clipping in Dasher that uses skipLen() to compute properly the dash phase &
> state
> - (D)Helpers: refined precision in cubicRootsInAB (float variant) + add
> fastXXXLen() to quickly estimate curve length from control points
>       moved findSubdivPoints() from (D)Stroker + added findClipPoints() to
> determine t values corresponding to curve intersections with the clip edges
> + added subdivideLineAt() to subdivide line segments
> - (D)MarlinRenderingEngine: disable stroker clipping if dasher clipping
> enabled (2nd clipping is counter-productive) + initialize new path
> simplifier if enabled (disabled by default) + log new settings
> - (D)Renderer: refined [quad/cubic]BreakIntoLinesAndAdd loops to enhance
> accuracy (smaller error related to 2nd ddx/y) with asymetric supixel counts
> - (D)Stroker: use new CurveBasicMonotonizer & CurveClipSplitter (code
> refactoring)
> - (D)TransformingPathConsumer2D: use CurveClipSplitter in PathClipFilter
> to clip filled shapes overlapping clipping edges
>             added CurveClipSplitter that subdivides curves (line, quad,
> cubic) at clip intersections (+ small padding to avoid precision issues)
>             added CurveBasicMonotonizer to monotonize curves (before in
> Stroker) to make it on initial curve in Dasher (more efficient than for all
> dashes)
> - (D)PathSimplifier: new basic path clipper (disabled by default) ignoring
> too small segments (radial distance threshold)
> - ClipShapeTest: improved test to use a small tolerance as clipped curves
> (at clip edges) has minor impact on computed offsets for stroked shapes and
> on dash positions: overall quality is improved as previously larger curves
> had more accumulated error on either dashes or stroke offsets
>
> Build & jtreg tests: OK
>
> Cheers,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180221/28af0e04/attachment.html>

From linuxhippy at gmail.com  Thu Feb 22 07:41:58 2018
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Thu, 22 Feb 2018 08:41:58 +0100
Subject: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask upload
	for xrender
Message-ID: <CAFvQSYSzOU0evjwuGrVL0MROWN51tJzsK3LOA8iTbcbJJw7vxg@mail.gmail.com>

Hi,

After achieving huge speedups with Marlin Laurent Bourg?s recently
proposed increasing the AA tile size of MaskBlit/MaskFill operations.
The 128x64 tiles size should help the Xrender pipeline a lot for
larger aa shapes. For smaller xrender stays rather slow.

To solve this issue am currently working on batching the AA tile mask
uploads in the xrender pipeline to improve the performance with
antialiasing enabled.
Batching can happen regardless of state-changes, so different shapes
with different properties can all be uploaded in one batch.
Furthermore that batching (resulting in larger uploads) allows for
mask upload using XShm (shared memory), reducing the number of data
copies and context switches.

Initial results seem very promising - beating the current OpenGL
implementation by a wide margin:

J2DBench, 20x20 ellipse antialiased:

XRender + deferred mask upload + XSHM:
>     Test(graphics.render.tests.fillOval) averaged
> 3.436728470039390E7 pixels/sec
>             with width1, !clip, Default, !alphacolor, ident,
> !extraalpha, single, !xormode, antialias, SrcOver, 20x20, bounce, to
> VolatileImg(Opaque)

XRender + deferred mask upload:
>     Test(graphics.render.tests.fillOval) averaged
> 3.0930638830897704E7 pixels/sec
>             with width1, !clip, Default, !alphacolor, ident,
> !extraalpha, single, !xormode, antialias, SrcOver, 20x20, bounce, to
> VolatileImg(Opaque)

OpenGL pipeline:
>      Test(graphics.render.tests.fillOval) averaged
> 1.3258861545909312E7 pixels/sec
>             with Default, !xormode, !extraalpha, single, bounce,
> 20x20, to VolatileImg(Opaque), ident, !clip, !alphacolor, antialias,
> SrcOver, width1

XRender as-is:
>       Test(graphics.render.tests.fillOval) averaged
>  6031195.796094009 pixels/sec
>              with !alphacolor, bounce, !extraalpha, !xormode,
> antialias, Default, single, ident, SrcOver, 20x20, to
> VolatileImg(Opaque), !clip, width1


And a real-world test: MigLayout Swing Benchmark with NimbusLnf, ms
for one iteration:

XRender-Deferred + SHM:
    AMD: 850 ms
    Intel: 1300 ms

OpenGL:
    AMD: 1260 ms
    Intel:  2580 ms

XRender (as is):
    AMD: 2620 ms
    Intel:  4690 ms

(AMD: AMD Kaveri 7650k / Intel: Intel Core i5 640M )


It is still in prototype state with a few rough edges and a few
corner-cases unimplemented (e.g. extra alpha with antialiasing),
but should be able to run most workloads:
http://93.83.133.214/webrev/
https://sourceforge.net/p/xrender-deferred/code/ref/default/

It is disabled by default, and can be enabled with -Dsun.java2d.xr.deferred=true
Shm upload is enabled with deferred and can be disabled with:
-Dsun.java2d.xr.shm=false

What would be the best way forward?
Would this have a chance to get into OpenJDK11 for platforms eith
XCB-based Xlib implementations?
Keeping in mind the dramatic performance increase,
even outperforming the current OpenGL pipeline, I really hope so.

Another change I would hope to see is a modification of the
maskblit/maskfill interfaces.
For now marlin has to rasterize into a byte[] tile, this array is
afterwards passed to the pipeline,
and the pipeline itself has to copy it again into some internal buffer.
With the enhancements described above, I see this copy process already
consuming ~5-10% of cpu cycles.
Instead the pipeline could provide a ByteBuffer to rasterize into to
Marlin, along with information regarding stride/width/etc.

Best regards, Clemens

Some background regarding the issue / implementation:

Since the creation of the xrender java2d backend, I was always
bothered how poor it performed with antialiasing enabled.
What the xrender backend does in this situation seems not to be that
common - the modern drivers basically stall the GPU for every single
AA tile (currently 32x32).

Pisces was so slow, xservers could consume the tiles more or less at
the speed pisces provided it.
However with the excellent work on Pisces's successor Marlin (big
thanks to Laurent Bourg?s), the bottleneck the xrender pipeline
presented was more and more evident.

One early approach to solve this weakness was to implement the AA
primitives using a modified version of Cairo,
sending a list of trapezoids to the x-server instead of the AA coverage masks.
However this approach has it's own performance issues (and is
considered hard to GPU-accelerate) and finally because of the
maintenance burden the idea was dropped.

The root of all evil is the immediate nature of Java2D:
Java2D calls into the backends with 32x32 tiles and expects them to
"immediatly" perform a bleding operation with the 32x32px alpha mask
provided.
In the xrender pipeline, this results in a XPutImage call for
uploading the coverage mask immediatly followed by an XRenderComposite
call performing the blending.
This means:
- a lot of traffic on the X11 protocol socket for transferring the
mask data -> context switches
- a lot of GPU stalls, because the uploaded data from system-memory is
immediatly used as input for the GPU operation
- a lot of driver/GPU state invalidation, because  various different
operations are mixed

What would help in this situation would be to combine all those small
RAM->VRAM uploads into a larger one,
followed by a series of blending operations.
So instead of: while(moreTiles)  {XPutImage(32x32);
XRenderComposite(32x32) } -> XPutImage(256x256); while(moreTiles)
{XRenderComposite(32x32)};

long story short: using xcb's socket handoff functionality this can be
done: https://lists.debian.org/debian-x/2008/10/msg00209.html
Socket handoff gives the user the control when to submit protocol to
the XServer (so the XRenderComposite commands can be queued without
beeing actually executed), while the AA tiles are buffered in a larger
marks - and before the XRenderComposite commands are sent to the
XServer we simply prepend the single, large XPutImage operation in
front.

The tradeoff is, during the socket is taken, the application has to
generate all the X11 protocol by itself - which means quite a bit new
code.
Every X function not implemented our own, will cause the socket to be
revoked, which incurs overhead and limites the timeframe batching can
be applied.
The good new is we don't have to handle every corner case - for
uncommon requests we simply fall back to the previous implementation,
xlib would grab the socket and the request would be generated in native code.

The implementation is careful not to introduce additional overhead
(except from a single additional if + method-call per primitive) in
cases where no antialiasing is used.
In case no MaskFill/Blit operations are enqueued, the old code-paths
are used exclusivly, without any change in operations.

Shm is done with 4 independent regions inside a single XShmImage.
After a region has been queued for upload using XShmPutImage, a
GetInputFocus request is queued - when the reply comes in, the
pipeline knows the region can be re-used again.
In case all regions are in-flight, the pipeline will gracefully
degrade to a normal XPutImage, which has the nice properties of not
introducing any sync overhead and cleaning the command-stream to get
the pending ShmPutImage operations processed.

From bourges.laurent at gmail.com  Fri Feb 23 13:02:23 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 23 Feb 2018 14:02:23 +0100
Subject: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask
 upload for xrender
In-Reply-To: <CAFvQSYSzOU0evjwuGrVL0MROWN51tJzsK3LOA8iTbcbJJw7vxg@mail.gmail.com>
References: <CAFvQSYSzOU0evjwuGrVL0MROWN51tJzsK3LOA8iTbcbJJw7vxg@mail.gmail.com>
Message-ID: <CAKjRUT7S9deZQZAByiMEF1eSr6F_X3+BJpyiqpWTU_wb21E1RQ@mail.gmail.com>

Hi Clemens,
As I am enjoying winter holidays, I will try your patch once at home.

It seems very promising and will try understanding changes to C code.
I will also test on my linux machines with nvidia cards (quadro 610 & 1070).

Cheers,
Laurent

Le 22 f?vr. 2018 8:42 AM, "Clemens Eisserer" <linuxhippy at gmail.com> a
?crit :

> Hi,
>
> After achieving huge speedups with Marlin Laurent Bourg?s recently
> proposed increasing the AA tile size of MaskBlit/MaskFill operations.
> The 128x64 tiles size should help the Xrender pipeline a lot for
> larger aa shapes. For smaller xrender stays rather slow.
>
> To solve this issue am currently working on batching the AA tile mask
> uploads in the xrender pipeline to improve the performance with
> antialiasing enabled.
> Batching can happen regardless of state-changes, so different shapes
> with different properties can all be uploaded in one batch.
> Furthermore that batching (resulting in larger uploads) allows for
> mask upload using XShm (shared memory), reducing the number of data
> copies and context switches.
>
> Initial results seem very promising - beating the current OpenGL
> implementation by a wide margin:
>
> J2DBench, 20x20 ellipse antialiased:
>
> XRender + deferred mask upload + XSHM:
> >     Test(graphics.render.tests.fillOval) averaged
> > 3.436728470039390E7 pixels/sec
> >             with width1, !clip, Default, !alphacolor, ident,
> > !extraalpha, single, !xormode, antialias, SrcOver, 20x20, bounce, to
> > VolatileImg(Opaque)
>
> XRender + deferred mask upload:
> >     Test(graphics.render.tests.fillOval) averaged
> > 3.0930638830897704E7 pixels/sec
> >             with width1, !clip, Default, !alphacolor, ident,
> > !extraalpha, single, !xormode, antialias, SrcOver, 20x20, bounce, to
> > VolatileImg(Opaque)
>
> OpenGL pipeline:
> >      Test(graphics.render.tests.fillOval) averaged
> > 1.3258861545909312E7 pixels/sec
> >             with Default, !xormode, !extraalpha, single, bounce,
> > 20x20, to VolatileImg(Opaque), ident, !clip, !alphacolor, antialias,
> > SrcOver, width1
>
> XRender as-is:
> >       Test(graphics.render.tests.fillOval) averaged
> >  6031195.796094009 pixels/sec
> >              with !alphacolor, bounce, !extraalpha, !xormode,
> > antialias, Default, single, ident, SrcOver, 20x20, to
> > VolatileImg(Opaque), !clip, width1
>
>
> And a real-world test: MigLayout Swing Benchmark with NimbusLnf, ms
> for one iteration:
>
> XRender-Deferred + SHM:
>     AMD: 850 ms
>     Intel: 1300 ms
>
> OpenGL:
>     AMD: 1260 ms
>     Intel:  2580 ms
>
> XRender (as is):
>     AMD: 2620 ms
>     Intel:  4690 ms
>
> (AMD: AMD Kaveri 7650k / Intel: Intel Core i5 640M )
>
>
> It is still in prototype state with a few rough edges and a few
> corner-cases unimplemented (e.g. extra alpha with antialiasing),
> but should be able to run most workloads:
> http://93.83.133.214/webrev/
> https://sourceforge.net/p/xrender-deferred/code/ref/default/
>
> It is disabled by default, and can be enabled with
> -Dsun.java2d.xr.deferred=true
> Shm upload is enabled with deferred and can be disabled with:
> -Dsun.java2d.xr.shm=false
>
> What would be the best way forward?
> Would this have a chance to get into OpenJDK11 for platforms eith
> XCB-based Xlib implementations?
> Keeping in mind the dramatic performance increase,
> even outperforming the current OpenGL pipeline, I really hope so.
>
> Another change I would hope to see is a modification of the
> maskblit/maskfill interfaces.
> For now marlin has to rasterize into a byte[] tile, this array is
> afterwards passed to the pipeline,
> and the pipeline itself has to copy it again into some internal buffer.
> With the enhancements described above, I see this copy process already
> consuming ~5-10% of cpu cycles.
> Instead the pipeline could provide a ByteBuffer to rasterize into to
> Marlin, along with information regarding stride/width/etc.
>
> Best regards, Clemens
>
> Some background regarding the issue / implementation:
>
> Since the creation of the xrender java2d backend, I was always
> bothered how poor it performed with antialiasing enabled.
> What the xrender backend does in this situation seems not to be that
> common - the modern drivers basically stall the GPU for every single
> AA tile (currently 32x32).
>
> Pisces was so slow, xservers could consume the tiles more or less at
> the speed pisces provided it.
> However with the excellent work on Pisces's successor Marlin (big
> thanks to Laurent Bourg?s), the bottleneck the xrender pipeline
> presented was more and more evident.
>
> One early approach to solve this weakness was to implement the AA
> primitives using a modified version of Cairo,
> sending a list of trapezoids to the x-server instead of the AA coverage
> masks.
> However this approach has it's own performance issues (and is
> considered hard to GPU-accelerate) and finally because of the
> maintenance burden the idea was dropped.
>
> The root of all evil is the immediate nature of Java2D:
> Java2D calls into the backends with 32x32 tiles and expects them to
> "immediatly" perform a bleding operation with the 32x32px alpha mask
> provided.
> In the xrender pipeline, this results in a XPutImage call for
> uploading the coverage mask immediatly followed by an XRenderComposite
> call performing the blending.
> This means:
> - a lot of traffic on the X11 protocol socket for transferring the
> mask data -> context switches
> - a lot of GPU stalls, because the uploaded data from system-memory is
> immediatly used as input for the GPU operation
> - a lot of driver/GPU state invalidation, because  various different
> operations are mixed
>
> What would help in this situation would be to combine all those small
> RAM->VRAM uploads into a larger one,
> followed by a series of blending operations.
> So instead of: while(moreTiles)  {XPutImage(32x32);
> XRenderComposite(32x32) } -> XPutImage(256x256); while(moreTiles)
> {XRenderComposite(32x32)};
>
> long story short: using xcb's socket handoff functionality this can be
> done: https://lists.debian.org/debian-x/2008/10/msg00209.html
> Socket handoff gives the user the control when to submit protocol to
> the XServer (so the XRenderComposite commands can be queued without
> beeing actually executed), while the AA tiles are buffered in a larger
> marks - and before the XRenderComposite commands are sent to the
> XServer we simply prepend the single, large XPutImage operation in
> front.
>
> The tradeoff is, during the socket is taken, the application has to
> generate all the X11 protocol by itself - which means quite a bit new
> code.
> Every X function not implemented our own, will cause the socket to be
> revoked, which incurs overhead and limites the timeframe batching can
> be applied.
> The good new is we don't have to handle every corner case - for
> uncommon requests we simply fall back to the previous implementation,
> xlib would grab the socket and the request would be generated in native
> code.
>
> The implementation is careful not to introduce additional overhead
> (except from a single additional if + method-call per primitive) in
> cases where no antialiasing is used.
> In case no MaskFill/Blit operations are enqueued, the old code-paths
> are used exclusivly, without any change in operations.
>
> Shm is done with 4 independent regions inside a single XShmImage.
> After a region has been queued for upload using XShmPutImage, a
> GetInputFocus request is queued - when the reply comes in, the
> pipeline knows the region can be re-used again.
> In case all regions are in-flight, the pipeline will gracefully
> degrade to a normal XPutImage, which has the nice properties of not
> introducing any sync overhead and cleaning the command-stream to get
> the pending ShmPutImage operations processed.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180223/743c2073/attachment.html>

From andrea.aime at geo-solutions.it  Sun Feb 25 21:16:00 2018
From: andrea.aime at geo-solutions.it (Andrea Aime)
Date: Sun, 25 Feb 2018 22:16:00 +0100
Subject: [OpenJDK 2D-Dev] Who to contact about potential JAI licence
	change?
In-Reply-To: <dd551c84-3111-8966-3e4a-21fdc7d72684@oracle.com>
References: <CA+nxMTu8fNnFieokO8ZTZ6qRrENK72EtRRMRq9dAro_A4f+yOQ@mail.gmail.com>
 <dd551c84-3111-8966-3e4a-21fdc7d72684@oracle.com>
Message-ID: <CA+nxMTsD90=NW5yAcOQLCO+2=3SP9bLc+r27J0pFbuQ4Ox9OVQ@mail.gmail.com>

Hi Phil,
sorry for the late follow up, and thanks a lot for your answer, it's quite
encouraging.

Where do I download JAI sources these days... humm... don't know honestly,
I have downloaded
the sources 10+ years ago and used it since :-)

About "proper" open source licence, since it's a library, it would be great
if the licence was not viral.
Ideally something widely compatible, like modified BSD or Apache 2, I guess
GPL with classpath
exception would do as well.

Thanks a lot for taking an interest in it, I understand there can be
difficulties, especially
on a project this old

Cheers
Andrea



On Tue, Feb 20, 2018 at 10:24 PM, Phil Race <philip.race at oracle.com> wrote:

> Hi Andrea,
>
> From where are you downloading the JAI source these days ?
> I assume GPL of some flavour would satisfy being a "proper" open source
> license.
> I will pass this request up the chain to see if there is any interest in
> doing it, but can make no promises.
>
> -phil.
>
>
> On 02/19/2018 03:52 AM, Andrea Aime wrote:
>
> Hi,
> Java Advanced Imaging has been unsupported for a long time, but it's still
> the best Java based
> image processing library (at least for large imagery cases, the tiled
> based, deferred computation
> approach is something software in other languages is still copying today).
>
> Its complete pluggability also makes it very easy to replace old buggy
> operations with newer ones, which is
> something done in open source projects like jai-ext: https://github.com/
> geosolutions-it/jai-ext
>
> However, its license is still a problem, it is not considered proper open
> source.
>
> Ideally all the Java portion would be useful, but in case that is a
> problem, just getting the interfaces relicenced
> would be of great help.
> So, is there anyone we could talk to about JAI relicencing? If more than
> one person/company needs to be
> contacted I'm happy to reach out, just need to get some contacts.
>
> Best regards
> Andrea Aime
>
>
>


-- 

Regards,

Andrea Aime

==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V
for more information.
==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054  Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39  339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo ? consentito esclusivamente al destinatario del messaggio,
per le finalit? indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalit? diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility  for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180225/04e42a04/attachment.html>

From bourges.laurent at gmail.com  Tue Feb 27 16:41:29 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Tue, 27 Feb 2018 17:41:29 +0100
Subject: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask
 upload for xrender
In-Reply-To: <CAFvQSYSzOU0evjwuGrVL0MROWN51tJzsK3LOA8iTbcbJJw7vxg@mail.gmail.com>
References: <CAFvQSYSzOU0evjwuGrVL0MROWN51tJzsK3LOA8iTbcbJJw7vxg@mail.gmail.com>
Message-ID: <CAKjRUT5U=BZCcvx898dr7UmecvDDu0sqwMNK5yj4W2r4A-i6pw@mail.gmail.com>

Hi Clemens,

Sorry this is a long email giving my feedback on your xrender efforts.

After achieving huge speedups with Marlin Laurent Bourg?s recently
> proposed increasing the AA tile size of MaskBlit/MaskFill operations.
> The 128x64 tiles size should help the Xrender pipeline a lot for
> larger aa shapes. For smaller xrender stays rather slow.
>

Thanks.
On my linux laptop (i7 + nvidia quadro), xrender is already faster than the
opengl backend (jdk11) on my MapBench tests.


> To solve this issue am currently working on batching the AA tile mask
> uploads in the xrender pipeline to improve the performance with
> antialiasing enabled.
> Batching can happen regardless of state-changes, so different shapes
> with different properties can all be uploaded in one batch.
> Furthermore that batching (resulting in larger uploads) allows for
> mask upload using XShm (shared memory), reducing the number of data
> copies and context switches.
>

First impressions:
I looked at your code and mostly understand it except how tiles are packed
in larger texture (illustration is missing, please) & fence handling.

Yesterday I looked at the OpenGL backend code and your new XRDeferedBackend
looks very closed to OGLRenderQueue (extends RenderQueue) so you may share
some code about the buffer queue ?
Moreover, OpenGL backend has a queue flusher although XRDeferedBackend has
not !

Does it mean that few buffered commands may be pending ... until the buffer
queue or texture is flushed ?

>
> It is still in prototype state with a few rough edges and a few
> corner-cases unimplemented (e.g. extra alpha with antialiasing),
> but should be able to run most workloads:
> http://93.83.133.214/webrev/
> https://sourceforge.net/p/xrender-deferred/code/ref/default/
>

I will give you later more details about your code (pseudo-review), but I
noticed that XRBackendNative uses putMaskNative (c) that seems more
efficient than the XRDeferedBackend (mask copy in java + XPutImage in c)...


>
> It is disabled by default, and can be enabled with
> -Dsun.java2d.xr.deferred=true
> Shm upload is enabled with deferred and can be disabled with:
> -Dsun.java2d.xr.shm=false
>

I merged your patch on latest jdk11 + pending marlin 0.9.1 patch and it
works well (except extra-alpha is missing).



> What would be the best way forward?
> Would this have a chance to get into OpenJDK11 for platforms with
> XCB-based Xlib implementations?
> Keeping in mind the dramatic performance increase,
> even outperforming the current OpenGL pipeline, I really hope so.
>

I made performance testing with nvidia hw (binary driver 390.12)
Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
Nvidia Quadro M1000M

1/ J2DBench results (AA on all shapes with size = 20 & 250):
options: bourgesl.github.io <https://github.com/bourgesl/bourgesl.github.io>
/j2dbench
<https://github.com/bourgesl/bourgesl.github.io/tree/master/j2dbench>/
options
<https://github.com/bourgesl/bourgesl.github.io/tree/master/j2dbench/options>
/default_2018.opt

Defered off vs on: ~ 1 to 15% slower
http://bourgesl.github.io/j2dbench/xr_results/Summary_Report.html

Defered enabled: SHM off vs on: ~ 3 to 10% faster
http://bourgesl.github.io/j2dbench/xr_results_shm/Summary_Report.html

See raw data:
https://github.com/bourgesl/bourgesl.github.io/tree/master/j2dbench/

Finally, J2DBench results do not show any gain on tested cases.
SHM is slightly better on nvidia (driver supposed to disable it ?) or
XRBackend / XCB is more efficient with SHM handling.

Perspectives:
- test smaller shapes (size=1 with width=5) to increase the tile packing
factor ?
- how to pack more efficiently the tiles into larger textures (padding) in
x or XY directions ? use multiple textures (pyramid) ?
- optimize tile copies anyway or the queue flushing ?


2/ MapBench tests with -Dsun.java2d.xr.deferred=false/true:

I found 2 cases with large gains (20% to 40% faster) whereas other maps
have 10% losses:
- dc_shp_alllayers_2013-00-30-07-00-47.ser {width=1400, height=800,
commands=135213}
Test                                             Threads    Ops    Med
Pct95    Avg    StdDev    Min    Max    FPS(med)    [ms/op]
*off*: dc_shp_alllayers_2013-00-30-07-00-47.ser         1    14
727.411    *728.847 *   727.394    1.127    725.197    729.833    1.375
*on*:  dc_shp_alllayers_2013-00-30-07-00-47.ser         1    23
443.919    *486.207*    456.228    19.807   438.598    486.902    2.253

- test_z_625k.ser {width=1272, height=1261, commands=23345}
Test                                             Threads    Ops    Med
Pct95    Avg    StdDev    Min    Max    FPS(med)    [ms/op]
*off*: test_z_625k.ser                                  1    96
108.856    *109.923*    108.915    0.588    107.886    111.762    9.186
*on*:  test_z_625k.ser                                  1    113
90.908    *92.837*     91.021     1.067    89.029     96.558    11.000

These two cases are the most complex maps (many small shapes) so the tile
packing is a big win (high tile count per texture upload and less uploads)

Here is my first conclusion:
- nvidia GPU (or drivers) are so fast & optimized that the XRender API
overhead is already very small in contrary to intel / AMD CPU that have
either slower GPU or less efficient drivers.
- anybody could test on other discrete GPU or recent CPU ?

Anyway I still think it is worth to go on improving this patch ... any idea
is welcome ?

Clemens, you could have a look to OpenJFX code as I remember OpenGL backend
is more efficient (buffering + texture uploads) so we could get some ideas
for improvements.


>
> Another change I would hope to see is a modification of the
> maskblit/maskfill interfaces.
> For now marlin has to rasterize into a byte[] tile, this array is
> afterwards passed to the pipeline,
> and the pipeline itself has to copy it again into some internal buffer.
> With the enhancements described above, I see this copy process already
> consuming ~5-10% of cpu cycles.
> Instead the pipeline could provide a ByteBuffer to rasterize into to
> Marlin, along with information regarding stride/width/etc.


That sounds a good idea, but I must study the impact on other backends...



> Some background regarding the issue / implementation:
>
> What would help in this situation would be to combine all those small
> RAM->VRAM uploads into a larger one,
> followed by a series of blending operations.
> So instead of: while(moreTiles)  {XPutImage(32x32);
> XRenderComposite(32x32) } -> XPutImage(256x256); while(moreTiles)
> {XRenderComposite(32x32)};
>
>
Why not larger texture than 256x256 ?
Is it uploaded completely in GPU (compromise) ? or partially ?

Is alignment important (16 ?) in GPU ? ie padding in x / y axis may improve
performance ?
Idem for row interleaving ? is it important ?
Why not pack the tile as an 1D contiguous array ?



>
> Shm is done with 4 independent regions inside a single XShmImage.
> After a region has been queued for upload using XShmPutImage, a
> GetInputFocus request is queued - when the reply comes in, the
> pipeline knows the region can be re-used again.
> In case all regions are in-flight, the pipeline will gracefully
> degrade to a normal XPutImage, which has the nice properties of not
> introducing any sync overhead and cleaning the command-stream to get
> the pending ShmPutImage operations processed.
>

I am a bit lost in how tiles are packed into the SHM_BUFFERS ... and why
the normal XPutImage is more complicated than in XRBackendNative.

PS: I can share (later) my variant of your patch (as I slightly modified
it) to fix typos, debugs ...

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20180227/2c9062fb/attachment.html>

From linuxhippy at gmail.com  Tue Feb 27 19:07:02 2018
From: linuxhippy at gmail.com (Clemens Eisserer)
Date: Tue, 27 Feb 2018 20:07:02 +0100
Subject: [OpenJDK 2D-Dev] Initial implementation for batched AA-mask
 upload for xrender
In-Reply-To: <CAKjRUT5U=BZCcvx898dr7UmecvDDu0sqwMNK5yj4W2r4A-i6pw@mail.gmail.com>
References: <CAFvQSYSzOU0evjwuGrVL0MROWN51tJzsK3LOA8iTbcbJJw7vxg@mail.gmail.com>
 <CAKjRUT5U=BZCcvx898dr7UmecvDDu0sqwMNK5yj4W2r4A-i6pw@mail.gmail.com>
Message-ID: <CAFvQSYTVgGXsV6GXGWz5GMxRiSfqSMQHg8tghut2iALiQLPCBA@mail.gmail.com>

Hi Laurent,

Thanks a lot for taking the time to test the deferred xrender pipeline.
Especially since the proprietary nvdia driver is the only one of
the accelerated xrender implementations I didnt test / benchmark against.

> On my linux laptop (i7 + nvidia quadro), xrender is already faster than the
> opengl backend (jdk11) on my MapBench tests.
> Finally, J2DBench results do not show any gain on tested cases.
> SHM is slightly better on nvidia (driver supposed to disable it ?) or
> XRBackend / XCB is more efficient with SHM handling.

This is really interesting - it seems the proprietary nvidia driver is
currently the only driver handling the current xrender operations well.
Back in 2009 I've written a standalone C benchmark to stress
the types of operations (JXRenderMark) performed by the xrender pipeline
and I know the nvidia people had a look at it,
great to see this actually turned out to be useful after all.

I could live with no performance win on nvidia, but I defintivly would
like to avoid regressions.
Seems I have to get access to a machine equipped with nvidia gpu
and test mapbench there.

> Yesterday I looked at the OpenGL backend code and your new XRDeferedBackend
> looks very closed to OGLRenderQueue (extends RenderQueue) so you may share
> some code about the buffer queue ?
> Moreover, OpenGL backend has a queue flusher although XRDeferedBackend has
> not !

Exactly, the RendereQueue based pipelines actually buffer their own protocol
which they "replay" later from a singel thread, whereas the deferred
xrender pipeline
directly generates X11 protocol and therefore avoids one level of indirection.
So despite the similarities, the actual implementation differs quite a bit.

> Does it mean that few buffered commands may be pending ... until the buffer
> queue or texture is flushed ?

The deferred Xrender pipeline behaves no different than the x11
or the "old" xrender pipeline one in this regard.
The self generated protocol is flushed when someone calls into a
native Xlib function,
by the callback returnSocketCB()l

> Here is my first conclusion:
> - nvidia GPU (or drivers) are so fast & optimized that the XRender API
> overhead is already very small in contrary to intel / AMD CPU that have
> either slower GPU or less efficient drivers.
> - anybody could test on other discrete GPU or recent CPU ?

In this case the overhead is caused by drivers, GPU utilization for most/all
of those workloads is typically minor.


> Why not larger texture than 256x256 ?
> Is it uploaded completely in GPU (compromise) ? or partially ?

Uploaded is only the area occupied by mask data.
256x256 is configureable (at least in code), and was a compromise between
SHM areas ni-flight and memory use.

> Is alignment important (16 ?) in GPU ? ie padding in x / y axis may improve
> performance ?
> Idem for row interleaving ? is it important ?
> Why not pack the tile as an 1D contiguous array ?

For ShmPutImage it doesn't matter, for XPutImage this is exactly what
the code in PutImage does.

> I am a bit lost in how tiles are packed into the SHM_BUFFERS ... and why the
> normal XPutImage is more complicated than in XRBackendNative.

This is an optimization - since we have to copy the data to the socket anyway,
we can use this copy-process to compensate for different scan between
the mask-buffer
and the width of the uploaded area (therefore data is copied to the
socket line-by-line).

> - how to pack more efficiently the tiles into larger textures (padding) in x or XY directions ? use multiple textures (pyramid) ?
This is an area which could need improvement.
For now tiles are layed out in a row one after another util the
remaining buffer-width < tile-width and
a next row is started.

> PS: I can share (later) my variant of your patch (as I slightly modified it)
> to fix typos, debugs ...

That would be great.

Thanks again & best regards, Clemens

From prahalad.kumar.narayanan at oracle.com  Wed Feb 28 09:30:22 2018
From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan)
Date: Wed, 28 Feb 2018 01:30:22 -0800 (PST)
Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-8198613] Test cases result in
 failure or timeout when run with OpenGL backend
Message-ID: <067761e1-a99b-4368-87f0-1037f06c7a63@default>

Hello Everyone

Good day to you.

Request your time in reviewing a minor fix for the bug
    . Bug: https://bugs.openjdk.java.net/browse/JDK-8198613
    . Title: Test cases result in failure or timeout when run with OpenGL backend

Root Cause:
    . OpenGL is not the default backend (or) the pipeline of choice for Java on different platforms.
    . However, we have been running many test cases enabling OpenGL with VM option -Dsun.java2d.opengl=True, on all the platforms which results in failures or time outs on many occasions.

Information on the Fix:
    . Kindly refer to the mail thread capturing review suggestions for a similar bug- JDK-8196451
          . Discussion Link: http://mail.openjdk.java.net/pipermail/2d-dev/2018-February/008932.html
          . To stabilize our test suite, we need not enable OpenGL pipeline where OS+OpenGL isn't the supported configuration.
          . If required, OpenGL pipeline could be enabled by using -vmoptions:"-Dsun.java2d.opengl=True" with Jtreg command.
    . As a follow-up from the discussion, I've now removed the VM option -Dsun.java2d.opengl=True for the test cases.
    . In addition, the test cases that were dedicated for OpenGL backend (in open/test/jdk/sun/java2d/OpenGL) have been moved to appropriate directories namely- open/test/jdk/java/awt/image/VolatileImage (or) open/test/jdk/java/awt/Graphics2D. 

Information on Testing:
    . The modified test cases have been tested on: Win-10, Win-10 (with hidpi), Win-7, Linux Ubuntu-16.04, Mac Sierra 10.12 platforms. 
    . Based on the test results, ProblemList.txt has been updated and has been captured as a part of this webrev.

Kindly review the changes at your convenience and provide your feedback
Link: http://cr.openjdk.java.net/~pnarayanan/8198613/webrev.00/

Thank you for your time in review
Have a good day

Prahalad N.