[OpenJDK 2D-Dev] RFR: 8252070 Some platform-specific BLIT optimizations are not effective

2020-08-28 Thread Sergey Bylokhov

Hello.
Please review the fix for jdk/client.

Bug: https://bugs.openjdk.java.net/browse/JDK-8252070
Fix: http://cr.openjdk.java.net/~serb/8252070/webrev.01

Some of our code assumes that the native system(XRender, D3D, OGL) makes some
effective optimizations, but in some cases, we can do better.

One of the areas for improvements is direct blitting. If the source is much
bigger than the destination we should not try to copy the non-existent area
and could cut coordinates accordingly.

The actual change is:
 951 Rectangle dst =
 952 new Rectangle(dx, dy, w, 
h).intersection(dstData.getBounds());
 953 if (dst.isEmpty()) {
 972 // return
 975 }
 979 sx += dst.x - dx;
 980 sy += dst.y - dy;


See performance data and some additional comments:
https://bugs.openjdk.java.net/browse/JDK-8252070?focusedCommentId=14365864&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14365864

--
Best regards, Sergey.


Re: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for libfontmanager

2020-08-28 Thread Sergey Bylokhov

On 27.08.2020 12:55, Philip Race wrote:

SAP or IBM can look at it if they want as a separate fix.


ok, +1




-phil.

On 8/27/20, 12:45 PM, Sergey Bylokhov wrote:

Hi, Phil.

Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a 
confirmation from the SAP gurus.

On 27.08.2020 12:39, Philip Race wrote:

Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html

This resolves the disabled compiler warnings in what is now quite a small 
fontmanager library.

I've built windows, mac and linux in our build system and run our full battery 
of automated tests and sanity checked manual.

A quick run down of how the warnings map to the changes

   DISABLED_WARNINGS_clang := sign-compare,

   DISABLED_WARNINGS_gcc := sign-compare unused-function 
int-to-pointer-cast,

Sign compare in both of the above are the reason for the majority of the 
changes in freetypeScaler.c
and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here 
https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or test that I 
was flying in the dark here
using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


   DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): error 
C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): warning 
C4244: '=': conversion from 'jlong' to 'long', possible loss of data

  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
error C2220: the following warning is treated as an error
  ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
warning C4146: unary minus operator applied to unsigned type, result still 
unsigned

./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): error 
C2220: the following warning is treated as an error
[ ./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
warning C4996: 'GetVersion': was declared deprecated

GetVersion isn't needed any more since we aren't likely to be running on 
anything older than XP !

-phil.










--
Best regards, Sergey.


Re: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs'

2020-08-28 Thread Sergey Bylokhov

Hi, Conor.

Please use such spec for the protected constructor: "Constructor for subclasses to 
call":
https://cr.openjdk.java.net/~psadhukhan/8250850/webrev.1/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalTheme.java.sdiff.html

Actually the current text is also fine to me, but looks like many people use 
the text above as a description.

On 28.08.2020 01:28, Conor Cleary wrote:

Hello all,

Could someone please review my changes for JDK-8250855, 'Address reliance on 
default constructors in the Java 2D APIs'? This issue relates to JDK-8250639 '☂ 
Address reliance on default constructors in the java.desktop module'. The 
changes address the reliance on default constructors by adding in basic 
constructors in the following classes:

  * java.awt.Image
  * java.awt.PrintJob
  * java.awt.font.GlyphVector
  * java.awt.font.LayoutPath
  * java.awt.font.LineMetrics
  * java.awt.image.AbstractMultiResolutionImage
  * java.awt.image.BufferStrategy
  * java.awt.image.ImageFilter
  * java.awt.image.RGBImageFilter
  * java.awt.image.VolatileImage
  * javax.print.PrintServiceLookup
  * javax.print.ServiceUI
  * javax.print.ServiceUIFactory
  * javax.print.StreamPrintServiceFactory
  * javax.print.event.PrintJobAdapter

A key issue is the accompanying description for each of the added constructors 
and is probably the feedback I would value most as it has been a point of 
discussion previously. I have included a specdiff to easily view the changes 
observed in the api documentation. Currently drafting a CSR for these changes.

  * webrev: 
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/
  * specdiff: 
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html
  * bug: https://bugs.openjdk.java.net/browse/JDK-8250855

Best Regards,

-Conor




--
Best regards, Sergey.


[OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

2020-08-28 Thread Philip Race

All,

Contingent on Project Skara (ie mercurial ->git / githib) going active 
for the JDK project on schedule
on 5th September, we intend to retire the jdk/client repo/forest as part 
of this transition.


In other words, once mercurial is shut down and we move to git there 
will ONLY be the main JDK repo

and all client pushes will go there.

We will be making some internal testing changes which we hope will help 
us spot any breakages
that pushes cause in time to prevent them making their way directly into 
a promoted build but they
can't completely replace the manual testing we have been doing, so we 
will also be
dependent on folks to be extra diligent from now on and not assume there 
is a gatekeeper

who will spot their mistakes.

But we do need some time to "flush" any last changes in client to jdk 
before mercurial shuts down.


So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to 
jdk/client should be

>> 9am PDT Tuesday 1st Sept 2020 <<

Anything pushed after that time may be lost forever :-)

We'll also  further enforce this as of 9am PDT Wednesday 2nd Sept 2020 
by making the client repo
mercurial repo read-only. The 24 hours is to help the integrator/gate 
keeper - not for your late pushes,
For example if there's a breakage we need to back out before integrating 
we might need this.

So not even "doc" or "test" changes - nothing please !

You may reasonably ask why then Tue/Wed for this if skara is not 
transitioning until Sat 5th September ?
The answer is that in an unfortunate coincidence of timing we have a big 
lab move that begins around
9am PT Wed 2nd September, and all our testing capabilities will be 
off-line for several days.

So any test jobs submitted after sometime Tuesday won't have time
to complete, and the lab move won't be complete until after the skara 
transition.


Any outstanding reviews that don't make the cut-off will of course have 
to be resubmitted as github pull requests
and any approvals they may have accumulated will need to be re-approved. 
All of this is of course true for
folks pushing directly to the mercurial main JDK repo - it is not 
related to the client repo retirement.


-Phil







[OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11

2020-08-28 Thread Philip Race

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

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

A rotuine 3rd party library upgrade.

All platforms build  + all tests pass.

-phil.


[OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs'

2020-08-28 Thread Conor Cleary

Hello all,

Could someone please review my changes for JDK-8250855, 'Address 
reliance on default constructors in the Java 2D APIs'? This issue 
relates to JDK-8250639 '☂ Address reliance on default constructors in 
the java.desktop module'. The changes address the reliance on default 
constructors by adding in basic constructors in the following classes:


 * java.awt.Image
 * java.awt.PrintJob
 * java.awt.font.GlyphVector
 * java.awt.font.LayoutPath
 * java.awt.font.LineMetrics
 * java.awt.image.AbstractMultiResolutionImage
 * java.awt.image.BufferStrategy
 * java.awt.image.ImageFilter
 * java.awt.image.RGBImageFilter
 * java.awt.image.VolatileImage
 * javax.print.PrintServiceLookup
 * javax.print.ServiceUI
 * javax.print.ServiceUIFactory
 * javax.print.StreamPrintServiceFactory
 * javax.print.event.PrintJobAdapter

A key issue is the accompanying description for each of the added 
constructors and is probably the feedback I would value most as it has 
been a point of discussion previously. I have included a specdiff to 
easily view the changes observed in the api documentation. Currently 
drafting a CSR for these changes.


 * webrev:
   
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/
 * specdiff:
   
http://cr.openjdk.java.net/~ccleary/issues/webrevs-store/8250855/webrevs/webrev.01/specdiff/overview-summary.html
 * bug: https://bugs.openjdk.java.net/browse/JDK-8250855

Best Regards,

-Conor



Re: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for libfontmanager

2020-08-28 Thread Magnus Ihse Bursie



On 2020-08-27 21:39, Philip Race wrote:

Bug : https://bugs.openjdk.java.net/browse/JDK-8074844
Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html

Looks good to me.

Thank you Phil for cleaning this up!

/Magnus



This resolves the disabled compiler warnings in what is now quite a 
small fontmanager library.


I've built windows, mac and linux in our build system and run our full 
battery of automated tests and sanity checked manual.


A quick run down of how the warnings map to the changes

  DISABLED_WARNINGS_clang := sign-compare,

  DISABLED_WARNINGS_gcc := sign-compare unused-function 
int-to-pointer-cast,


Sign compare in both of the above are the reason for the majority of 
the changes in freetypeScaler.c

and also the change in hb-jdk.h


unused-function was _free_nothing in
src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc


int-to-pointer-cast was an issue for 32 bit as raised here 
https://bugs.openjdk.java.net/browse/JDK-8250605
when a previous removal broke 32 bit Linux. Since we don't build or 
test that I was flying in the dark here

using the warnings from that bug. The changes for this are those in

src/java.desktop/share/native/libfontmanager/DrawGlyphList.c
src/java.desktop/unix/native/libfontmanager/X11FontScaler.c


  DISABLED_WARNINGS_microsoft := 4018 4146 4244 4996,

The unique windows warnings were
./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
error C2220: the following warning is treated as an error
 ./open/src/java.desktop/share/native/libfontmanager/HBShaper.c(216): 
warning C4244: '=': conversion from 'jlong' to 'long', possible loss 
of data


 ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
error C2220: the following warning is treated as an error
 ./open/src/java.desktop/share/native/libfontmanager/freetypeScaler.c(1216): 
warning C4146: unary minus operator applied to unsigned type, result 
still unsigned


./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
error C2220: the following warning is treated as an error
[ 
./open/src/java.desktop/windows/native/libfontmanager/lcdglyph.c(128): 
warning C4996: 'GetVersion': was declared deprecated


GetVersion isn't needed any more since we aren't likely to be running 
on anything older than XP !


-phil.