Re: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is selected via system property

2018-03-20 Thread Prahalad Kumar Narayanan 
Hello Phil

Good day to you. 

Thank you for the explanation. I understand your point now.
The code changes look good.

Thank you
Have a good day

Prahalad N.


- Original Message -
From: Phil Race 
Sent: Wednesday, March 21, 2018 12:14 AM
To: Prahalad Kumar Narayanan; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is 
selected via system property

I typed
+(!(FontUtilities.useT2K && !FontUtilities.useLegacy) ?

when I actually meant

+((!FontUtilities.useT2K && !FontUtilities.useLegacy) ?

ie the first "!" was supposed to be inside .. 

I decided to add a debugging option to make it easier to tell what you'd got
and then further decided to add code that falls back to freetype if you
asked for T2K but it isn't there.


http://cr.openjdk.java.net/~prr/8199789.1

I've tested it with openjdk + oracle JDK builds.

I think it'll do for now until T2K is removed.

-phil.
On 03/20/2018 02:30 AM, Prahalad Kumar Narayanan wrote:
Hello Phil

Good day to you.

I imported your patch and checked the resulting build.
Warnings showed up as expected with use of "t2k" or "legacy" in the VM option 
-Dsun.java2d.font.scaler.

However, I'm unable to interpret this line and its intended outcome. 
It also adds a new value for sun.java2d.font.scaler of "legacy" which means 
"t2k" but as it was used in by default.

In my observation with logs, setting VM option to 
"t2k" instantiates T2KFontScaler and 
"legacy" instantiates FreetypeFontScaler.
If this is the intended behavior, the code changes work as expected.

Thank you
Have a good day

Prahalad N.


-Original Message-
From: Phil Race 
Sent: Tuesday, March 20, 2018 1:09 AM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is 
selected via system property

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

https://bugs.openjdk.java.net/browse/JDK-8193017 made freetype the default font 
rasteriser for all JDK builds.

We plan to remove t2k completely including references to it from open sources, 
before JDK 11 GA's

But for now it is still there for debugging but to make it clear this small fix 
makes a warning get printed if you try to use it.

It also adds a new value for sun.java2d.font.scaler of "legacy" which means 
"t2k" but as it was used in by default.

The subtle issue is that "t2k" disables using GDI for LCD text.
"legacy" gets you exactly what JDK did by default in 6u10 -> JDK 10 inclusive.

So it may be more useful for a debugging comparison flag.

-phil.

Re: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is selected via system property

2018-03-20 Thread Phil Race 

I typed

+ (!(FontUtilities.useT2K && !FontUtilities.useLegacy) ? when I actually 
meant + ((!FontUtilities.useT2K && !FontUtilities.useLegacy) ? ie the 
first "!" was supposed to be inside ..



I decided to add a debugging option to make it easier to tell what you'd got
and then further decided to add code that falls back to freetype if you
asked for T2K but it isn't there.


http://cr.openjdk.java.net/~prr/8199789.1

I've tested it with openjdk + oracle JDK builds.

I think it'll do for now until T2K is removed.


-phil.
On 03/20/2018 02:30 AM, Prahalad Kumar Narayanan wrote:

Hello Phil

Good day to you.

I imported your patch and checked the resulting build.
Warnings showed up as expected with use of "t2k" or "legacy" in the VM option 
-Dsun.java2d.font.scaler.

However, I'm unable to interpret this line and its intended outcome.

It also adds a new value for sun.java2d.font.scaler of "legacy" which means 
"t2k" but as it was used in by default.

In my observation with logs, setting VM option to
 "t2k" instantiates T2KFontScaler and
 "legacy" instantiates FreetypeFontScaler.
If this is the intended behavior, the code changes work as expected.

Thank you
Have a good day

Prahalad N.


-Original Message-
From: Phil Race
Sent: Tuesday, March 20, 2018 1:09 AM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is 
selected via system property

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

https://bugs.openjdk.java.net/browse/JDK-8193017 made freetype the default font 
rasteriser for all JDK builds.

We plan to remove t2k completely including references to it from open sources, 
before JDK 11 GA's

But for now it is still there for debugging but to make it clear this small fix 
makes a warning get printed if you try to use it.

It also adds a new value for sun.java2d.font.scaler of "legacy" which means 
"t2k" but as it was used in by default.

The subtle issue is that "t2k" disables using GDI for LCD text.
"legacy" gets you exactly what JDK did by default in 6u10 -> JDK 10 inclusive.

So it may be more useful for a debugging comparison flag.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8199870: colorimaging.md needs to remove mention of KCMS

2018-03-20 Thread Sergey Bylokhov 

+1

On 20/03/2018 09:54, Phil Race wrote:

Bug: https://bugs.openjdk.java.net/browse/JDK-8199870
Diff: inline below

The legal attribution file src/java.desktop/share/legal/colorimaging.md
references the Kodak Color Management System which not only
was never in OpenJDK, but is not in Oracle JDK anymore either ..

This simple patch just updates the file to reflect this.
It still needs to be there since Kodak contributed to the implementation
of  number of the java/awt/image API classes.

Diff below.

-phil.

diff --git a/src/java.desktop/share/legal/colorimaging.md 
b/src/java.desktop/share/legal/colorimaging.md

--- a/src/java.desktop/share/legal/colorimaging.md
+++ b/src/java.desktop/share/legal/colorimaging.md
@@ -1,4 +1,4 @@
-## Eastman Kodak Company: Kodak Color Management System (kcms) and 
portions of color management and imaging software
+## Eastman Kodak Company: Portions of color management and imaging 
software


  ### Eastman Kodak Notice
  




--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] [11] RFR JDK-7031957: DIB header of type BITMAPV2INFOHEADER & BITMAPV3INFOHEADER is not supported in BMPImageReader

2018-03-20 Thread Phil Race 

In that case the patch is fine.

-phil.

On 03/20/2018 12:15 AM, Jayathirth D V wrote:


HI Phil,

Please find my observation:

In case of DIB header type BITMAPINFOHEADER/ BITMAPV4HEADER/ 
BITMAPV5HEADER, Microsoft 
documentation(https://msdn.microsoft.com/en-us/library/dd183376(v=vs.85).aspx 
 
) mentions that mask values are valid only when compression type is 
BI_BITFIELDS. When compression type is BI_RGB which ii no compression, 
Microsoft document mentions that


1)For 16 bpp : “The relative intensities of red, green, and blue are 
represented with five bits for each color component. The value for 
blue is in the least significant five bits, followed by five bits each 
for green and red. The most significant bit is not used.”. So 
basically it should be RGB555.


2)For 32 bpp : “Each DWORD in the bitmap array represents the relative 
intensities of blue, green, and red for a pixel. The value for blue is 
in the least significant 8 bits, followed by 8 bits each for green and 
red. The high byte in each DWORD is not used”. So basically it should 
be XRGB.


This is why we have redMask = 0x7C00, greenMask = 0x3E0, blueMask = 
0x1F in case of 16bpp and redMask   = 0x00FF, greenMask = 
0xFF00, blueMask  = 0x00FFfor 32bpp for all the three standard 
formats BITMAPINFOHEADER, BITMAPV4HEADER and BITMAPV5HEADER.


Since BITMAPV2INFOHEADER & BITMAPV3INFOHEADER support falls in between 
that of other Microsoft documented DIB header types it is good that we 
follow the same approach in case of BITMAPV2INFOHEADER & 
BITMAPV3INFOHEADER also.


Please let us know your inputs.

Thanks,

Jay

*From:*Phil Race
*Sent:* Monday, March 19, 2018 11:07 PM
*To:* Jayathirth D V; 2d-dev
*Subject:* Re: [OpenJDK 2D-Dev] [11] RFR JDK-7031957: DIB header of 
type BITMAPV2INFOHEADER & BITMAPV3INFOHEADER is not supported in 
BMPImageReader


Since the principal addition of these formats is to add explicit fields
for supporting the bitmasks for accessing R/G/B/A it seems odd to
see there is code like this which ignores it when the data is uncompressed
by using these hardcoded values :

  456 if ((int)compression == BI_RGB) {
  457 redMask = 0x7C00;
  458 greenMask = 0x3E0;
  459 blueMask = 0x1F;


I do see that it seems likely you copied this from the 108/124 case
but I'd like to see some proof that this is correct.


-phil.

On 03/14/2018 03:39 AM, Jayathirth D V wrote:

Hello All,

Please review the following solution in JDK11 :

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

Webrev : http://cr.openjdk.java.net/~jdv/7031957/webrev.00/


_Issue:_ If we try to read any BMP image of DIB header type
BITMAPV2INFOHEADER/ BITMAPV3INFOHEADER, we get IOException
mentioning the BMP image type in not yet implemented.

_Root cause: _ BMPImageReader doesn’t support DIB header types
BITMAPV2INFOHEADER/ BITMAPV3INFOHEADER we support only
BITMAPCOREHEADER, BITMAPINFOHEADER, BITMAPV4HEADER & BITMAPV5HEADER.

_Solution:_ Many other tools like GIMP, Microsoft PowerPoint,
IrfanView support BITMAPV2INFOHEADER & BITMAPV3INFOHEADER format
BMP images. We can consider BITMAPV2INFOHEADER &
BITMAPV3INFOHEADER header types having functionality in between
that of BITMAPINFOHEADER & BITMAPV4HEADER. BITMAPINFOHEADER with
type BITFIELDS & extra 4 bytes for alpha channel or First 56 bytes
of BITMAPV4HEADER is nothing but BITMAPV3INFOHEADER.

To support BITMAPV2INFOHEADER & BITMAPV3INFOHEADER we can use
similar approach of what we are doing while decoding first 56
bytes under BITMAPV4HEADER. So I have added additional “if()” to
do the same, we can merge decoding of BITMAPV2INFOHEADER &
BITMAPV3INFOHEADER at the same place where we are decoding
BITMAPV4HEADER but we need to add many branch conditions to follow
that approach.

Thanks,

Jay

[OpenJDK 2D-Dev] RFR: 8199870: colorimaging.md needs to remove mention of KCMS

2018-03-20 Thread Phil Race 

Bug: https://bugs.openjdk.java.net/browse/JDK-8199870
Diff: inline below

The legal attribution file src/java.desktop/share/legal/colorimaging.md
references the Kodak Color Management System which not only
was never in OpenJDK, but is not in Oracle JDK anymore either ..

This simple patch just updates the file to reflect this.
It still needs to be there since Kodak contributed to the implementation
of  number of the java/awt/image API classes.

Diff below.

-phil.

diff --git a/src/java.desktop/share/legal/colorimaging.md 
b/src/java.desktop/share/legal/colorimaging.md

--- a/src/java.desktop/share/legal/colorimaging.md
+++ b/src/java.desktop/share/legal/colorimaging.md
@@ -1,4 +1,4 @@
-## Eastman Kodak Company: Kodak Color Management System (kcms) and 
portions of color management and imaging software

+## Eastman Kodak Company: Portions of color management and imaging software

 ### Eastman Kodak Notice

Re: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is selected via system property

2018-03-20 Thread Prahalad Kumar Narayanan 
Hello Phil

Good day to you.

I imported your patch and checked the resulting build.
Warnings showed up as expected with use of "t2k" or "legacy" in the VM option 
-Dsun.java2d.font.scaler.

However, I'm unable to interpret this line and its intended outcome. 
> It also adds a new value for sun.java2d.font.scaler of "legacy" which means 
> "t2k" but as it was used in by default.

In my observation with logs, setting VM option to 
"t2k" instantiates T2KFontScaler and 
"legacy" instantiates FreetypeFontScaler.
If this is the intended behavior, the code changes work as expected.

Thank you
Have a good day

Prahalad N.


-Original Message-
From: Phil Race 
Sent: Tuesday, March 20, 2018 1:09 AM
To: 2d-dev
Subject: [OpenJDK 2D-Dev] RFR 8199789: Emit a warning message when t2k is 
selected via system property

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

https://bugs.openjdk.java.net/browse/JDK-8193017 made freetype the default font 
rasteriser for all JDK builds.

We plan to remove t2k completely including references to it from open sources, 
before JDK 11 GA's

But for now it is still there for debugging but to make it clear this small fix 
makes a warning get printed if you try to use it.

It also adds a new value for sun.java2d.font.scaler of "legacy" which means 
"t2k" but as it was used in by default.

The subtle issue is that "t2k" disables using GDI for LCD text.
"legacy" gets you exactly what JDK did by default in 6u10 -> JDK 10 inclusive.

So it may be more useful for a debugging comparison flag.

-phil.

Re: [OpenJDK 2D-Dev] [11] RFR JDK-7031957: DIB header of type BITMAPV2INFOHEADER & BITMAPV3INFOHEADER is not supported in BMPImageReader

2018-03-20 Thread Jayathirth D V 
HI Phil,

 

Please find my observation:

In case of DIB header type BITMAPINFOHEADER/ BITMAPV4HEADER/ BITMAPV5HEADER, 
Microsoft 
documentation(https://msdn.microsoft.com/en-us/library/dd183376(v=vs.85).aspx ) 
mentions that mask values are valid only when compression type is BI_BITFIELDS. 
When compression type is BI_RGB which ii no compression, Microsoft document 
mentions that

 

1)  For 16 bpp : "The relative intensities of red, green, and blue are 
represented with five bits for each color component. The value for blue is in 
the least significant five bits, followed by five bits each for green and red. 
The most significant bit is not used.". So basically it should be RGB555.

2)  For 32 bpp : "Each DWORD in the bitmap array represents the relative 
intensities of blue, green, and red for a pixel. The value for blue is in the 
least significant 8 bits, followed by 8 bits each for green and red. The high 
byte in each DWORD is not used". So basically it should be XRGB.

 

This is why we have redMask = 0x7C00, greenMask = 0x3E0, blueMask = 0x1F in 
case of 16bpp and redMask   = 0x00FF, greenMask = 0xFF00, blueMask  = 
0x00FFfor 32bpp for all the three standard formats BITMAPINFOHEADER, 
BITMAPV4HEADER and BITMAPV5HEADER.

 

Since BITMAPV2INFOHEADER & BITMAPV3INFOHEADER support falls in between that of 
other Microsoft documented DIB header types it is good that we follow the same 
approach in case of BITMAPV2INFOHEADER & BITMAPV3INFOHEADER also.

 

Please let us know your inputs.

 

Thanks,

Jay

 

From: Phil Race 
Sent: Monday, March 19, 2018 11:07 PM
To: Jayathirth D V; 2d-dev
Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-7031957: DIB header of type 
BITMAPV2INFOHEADER & BITMAPV3INFOHEADER is not supported in BMPImageReader

 

Since the principal addition of these formats is to add explicit fields
for supporting the bitmasks for accessing R/G/B/A it seems odd to
see there is code like this which ignores it when the data is uncompressed
by using these hardcoded values :

 456 if ((int)compression == BI_RGB) {
 457 redMask = 0x7C00;
 458 greenMask = 0x3E0;
 459 blueMask = 0x1F;


I do see that it seems likely you copied this from the 108/124 case
but I'd like to see some proof that this is correct.


-phil.

On 03/14/2018 03:39 AM, Jayathirth D V wrote:

Hello All,

 

Please review the following solution in JDK11 :

 

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

Webrev : HYPERLINK 
"http://cr.openjdk.java.net/%7Ejdv/7031957/webrev.00/"http://cr.openjdk.java.net/~jdv/7031957/webrev.00/
 

 

Issue: If we try to read any BMP image of DIB header type BITMAPV2INFOHEADER/ 
BITMAPV3INFOHEADER, we get IOException mentioning the BMP image type in not yet 
implemented.

 

Root cause:  BMPImageReader doesn't support DIB header types 
BITMAPV2INFOHEADER/ BITMAPV3INFOHEADER we support only BITMAPCOREHEADER, 
BITMAPINFOHEADER, BITMAPV4HEADER & BITMAPV5HEADER.

 

Solution: Many other tools like GIMP, Microsoft PowerPoint, IrfanView support 
BITMAPV2INFOHEADER & BITMAPV3INFOHEADER format BMP images. We can consider 
BITMAPV2INFOHEADER & BITMAPV3INFOHEADER header types having functionality in 
between that of BITMAPINFOHEADER & BITMAPV4HEADER. BITMAPINFOHEADER with type 
BITFIELDS & extra 4 bytes for alpha channel or First 56 bytes of BITMAPV4HEADER 
is nothing but BITMAPV3INFOHEADER.

 

To support BITMAPV2INFOHEADER & BITMAPV3INFOHEADER we can use similar approach 
of what we are doing while decoding first 56 bytes under BITMAPV4HEADER. So I 
have added additional "if()" to do the same, we can merge decoding of 
BITMAPV2INFOHEADER & BITMAPV3INFOHEADER at the same place where we are decoding 
BITMAPV4HEADER but we need to add many branch conditions to follow that 
approach.

 

Thanks,

Jay