Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Thomas Stüfe]

Hi Phil,

This is a nice change! And will make setting up the windows build env much
easier.

Change itself seems fine at a cursory glance. I also tested the build on
Win7 with VS2013 (before, I used to build with a hand-compiled version of
the freetypelib), and it worked fine.

I attempted to test the 32bit build but that seems to have bitrotted, I ran
into errors not having anything to do with your change.

Best Regards, Thomas

On Fri, Mar 9, 2018 at 11:10 PM, Phil Race  wrote:

> Bug: https://bugs.openjdk.java.net/browse/JDK-8193017
> Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html
>
> This fix is will make building openjdk somewhat easier as it removes
> the dependence on an OpenJDK developer on Windows or Mac going
> off and downloading and building freetype source themselves .. or
> using XQuartz on Mac etc.
>
> It also means it will be somewhat easier for updating official OpenJDK
> builds to use a more modern freetype. The pre-compiled binary is a pain
> inside Oracle too.
>
> On Linux and Solaris platforms the build will still default to using
> the system installed freetype library. However this can easily be
> over-ridden by adding  a configure parameter : --with-freetype=bundled
> The other valid option being "system" which, is of however never not valid
> on Windows  or Mac. So --with-freetype include is no longer a path.
> The auto-discovery of the location of system library and headers has
> worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10
>
> But just in case it doesn't you can also still use
> --with-freetype-include and --with-freetype-lib
> which must both be specified and imply --with-freetype=system
>
> The docs have been updated to remove discussion of the obsoleted
> requirements
>
> Sharp eyes will also notice that it now makes Freetype the preferred
> rasteriser
> over the closed source T2K, even for Oracle JDK builds :
>
> http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/sha
> re/classes/sun/font/FontScaler.java.sdiff.html
>
> Since freetype != t2k there *will* be some very minor rasterization
> differences.
> Such cases are likely not a bug, but a feature :-)
> Since we previously and now mostly used GDI for LCD text on Windows and
> also generally defer to CoreText on Mac, the importance of the differences
> may not be great.
> But if you see any really bad rendering (I haven't) let me know.
>
> make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
> proposing to remove the devkit references to freetype but it was suggested
> to leave that alone for now.
>
> 99% of the change is simply importing the freetype 2.9 files "as is"
> The UPDATING.txt file provides some background on the import process.
>
> I have built this every-which-way and tested it too .. it is of course
> possible
> there's a problem I've missed so try it out yourself if you can.
>
> -phil.
>
>
>
>
>
>
>
>

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Philip Race]

It is correct as is ..

-phil.

On 3/9/18, 3:49 PM, Sergey Bylokhov wrote:

I am not an expert here, but the LICENSE.TXT is a little bit different.
It states that "This means  that *you* must choose  *one* of the  two 
licenses described below,.".
So I do not know should we select the license and provide the text 
only for one or for both.


On 09/03/2018 15:28, Philip Race wrote:

Just to be clear, I mean we don't import it to each of the source files.
But it is there in the file legal/freetype.md in this webrev.

On 3/9/18, 3:26 PM, Philip Race wrote:


No.

-phil.

On 3/9/18, 3:23 PM, Sergey Bylokhov wrote:

Hi, Phil
Headers of the new files refer to LICENSE.TXT. Should we import it 
as well?


On 09/03/2018 14:10, Phil Race wrote:

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official 
OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a 
pain

inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : 
--with-freetype=bundled
The other valid option being "system" which, is of however never 
not valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the 
preferred rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor 
rasterization differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on 
Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Sergey Bylokhov]

I am not an expert here, but the LICENSE.TXT is a little bit different.
It states that "This means  that *you* must choose  *one* of the  two 
licenses described below,.".
So I do not know should we select the license and provide the text only 
for one or for both.


On 09/03/2018 15:28, Philip Race wrote:

Just to be clear, I mean we don't import it to each of the source files.
But it is there in the file legal/freetype.md in this webrev.

On 3/9/18, 3:26 PM, Philip Race wrote:


No.

-phil.

On 3/9/18, 3:23 PM, Sergey Bylokhov wrote:

Hi, Phil
Headers of the new files refer to LICENSE.TXT. Should we import it as 
well?


On 09/03/2018 14:10, Phil Race wrote:

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not 
valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.













--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Philip Race]

Just to be clear, I mean we don't import it to each of the source files.
But it is there in the file legal/freetype.md in this webrev.

On 3/9/18, 3:26 PM, Philip Race wrote:


No.

-phil.

On 3/9/18, 3:23 PM, Sergey Bylokhov wrote:

Hi, Phil
Headers of the new files refer to LICENSE.TXT. Should we import it as 
well?


On 09/03/2018 14:10, Phil Race wrote:

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not 
valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Philip Race]

No.

-phil.

On 3/9/18, 3:23 PM, Sergey Bylokhov wrote:

Hi, Phil
Headers of the new files refer to LICENSE.TXT. Should we import it as 
well?


On 09/03/2018 14:10, Phil Race wrote:

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not 
valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of 
course possible

there's a problem I've missed so try it out yourself if you can.

-phil.

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Sergey Bylokhov]

Hi, Phil
Headers of the new files refer to LICENSE.TXT. Should we import it as well?

On 09/03/2018 14:10, Phil Race wrote:

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not valid
on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the differences
may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was suggested
to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of course 
possible

there's a problem I've missed so try it out yourself if you can.

-phil.










--
Best regards, Sergey.

Re: [OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Erik Joelsson]

Build changes look good.

/Erik


On 2018-03-09 14:10, Phil Race wrote:

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not 
valid

on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html 



Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the 
differences

may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was 
suggested

to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of course 
possible

there's a problem I've missed so try it out yourself if you can.

-phil.

[OpenJDK 2D-Dev] RFR: 8193017: Import freetype sources into OpenJDK source tree

[Phil Race]

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

This fix is will make building openjdk somewhat easier as it removes
the dependence on an OpenJDK developer on Windows or Mac going
off and downloading and building freetype source themselves .. or
using XQuartz on Mac etc.

It also means it will be somewhat easier for updating official OpenJDK
builds to use a more modern freetype. The pre-compiled binary is a pain
inside Oracle too.

On Linux and Solaris platforms the build will still default to using
the system installed freetype library. However this can easily be
over-ridden by adding  a configure parameter : --with-freetype=bundled
The other valid option being "system" which, is of however never not valid
on Windows  or Mac. So --with-freetype include is no longer a path.
The auto-discovery of the location of system library and headers has
worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10

But just in case it doesn't you can also still use
--with-freetype-include and --with-freetype-lib
which must both be specified and imply --with-freetype=system

The docs have been updated to remove discussion of the obsoleted 
requirements


Sharp eyes will also notice that it now makes Freetype the preferred 
rasteriser

over the closed source T2K, even for Oracle JDK builds :

http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html

Since freetype != t2k there *will* be some very minor rasterization 
differences.

Such cases are likely not a bug, but a feature :-)
Since we previously and now mostly used GDI for LCD text on Windows and
also generally defer to CoreText on Mac, the importance of the differences
may not be great.
But if you see any really bad rendering (I haven't) let me know.

make/devkit/createMacosxDevkit6.sh is an empty diff  .. I was
proposing to remove the devkit references to freetype but it was suggested
to leave that alone for now.

99% of the change is simply importing the freetype 2.9 files "as is"
The UPDATING.txt file provides some background on the import process.

I have built this every-which-way and tested it too .. it is of course 
possible

there's a problem I've missed so try it out yourself if you can.

-phil.

Re: [OpenJDK 2D-Dev] [11] Upgrade to Marlin renderer 0.9.1

[Laurent Bourgès]

Hi Sergey & Phil,

Could you review the submitted marlin webrev soon ?

I will revert the tile size change in MarlinProperties (6,7 => 5,5) to
avoid any problem for now: 2 lines fix.

As proposed before, supporting larger tiles in 2d pipelines needs many
small tuning and can be done in follow-up issues (d3d, ogl, gdi...) as it
requires lots of testing.

I prefer having Marlin 0.9.1 patch accepted asap.

Laurent

Le 8 mars 2018 23:57, "Sergey Bylokhov"  a
écrit :

> On 08/03/2018 14:02, Laurent Bourgès wrote:
>
>> I suppose the queue is drained too quickly on my fast gpu and is too
>> small to feed the gpu... maybe I am wron
>>
> Profiling will help here. on macOS you can user Instruments which can
> profile cpu and gpu.
>
> Definitely it is more related to awt... and propose to postpone using
>> large tiles on other platforms than linux for the moment.
>>
>> How is it enabled ? Using sun.java2d.d3d=false ?
>>
>
> Yes "sun.java2d.d3d=false" or it can be selected automatically if d3d
> pipeline is unsupported (or video card is blacklisted).
>
>
> --
> Best regards, Sergey.
>