Re: tutorial

[Glenn Holmer]

On 10/01/2018 05:45 PM, Karl-Philipp Richter wrote:
> Am 27.09.2018 um 16:39 schrieb Glenn Holmer:
>> On https://openjfx.io/openjfx-docs/ I don't see any content, just
>> buttons and links that don't seem to do anything. Tried both Firefox and
>> Chrome. Is it just me?

> Works for me on Firefox on Ubuntu 18.04. I have NoScript installed and
> needed to active some scripts (jsdelivr.net) in order to be able to see
> the content. Provide a screenshot if you have further trouble.

I tried it again this afternoon and it was working properly.

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

Re: tutorial

[Karl-Philipp Richter]

Hi,

Am 27.09.2018 um 16:39 schrieb Glenn Holmer:
> On https://openjfx.io/openjfx-docs/ I don't see any content, just
> buttons and links that don't seem to do anything. Tried both Firefox and
> Chrome. Is it just me?
Works for me on Firefox on Ubuntu 18.04. I have NoScript installed and
needed to active some scripts (jsdelivr.net) in order to be able to see
the content. Provide a screenshot if you have further trouble.

-Kalle

Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c

[Phil Race]

I filed two bugs
JDK-8211362: Restrict export of libjpeg symbols from libjavafx_iio.so
JDK-8211363: Use platform version of libjpeg on Linux

-phil

On 10/01/2018 02:01 PM, Phil Race wrote:

On 10/1/2018 1:55 PM, Phil Race wrote:

The JDK has shipped a libjpeg since, well, forever.


PS .. we now call it libjavajpeg.so but that is recent (JDK 9).

-phil.


For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.

The JDK approach used to be tediously maintained mapfiles. But 
recently it
was switched to use compiler directives. The default for such a 
library as
libjavafx_iio.so is that symbols aren't exported, and we don't need 
to touch
the imported source files, just add the JNIEXPORT directive to the 
declarations of
the JNI functions in the JDK's own source files which are compiled 
into the library.

And of course some makefile work.

See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html

We can do something like this for FX in a follow-on bug

Another follow-on bug opportunity, is for FX to do what JDK 11 does, 
which
is to defer to the system libjpeg on Linux (and Solaris, but not 
relevant to FX).
So libjavafx_iio.so on Linux would become just a small entry point to 
the

platform JPEG library.

-phil.

On 10/01/2018 10:59 AM, Johan Vos wrote:
Unrelated to the patch, I wonder if there is a better way to include 
this

functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on 
ios, where

we build a static executable).

Is it an option to prefix the public symbols?

- Johan


On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte 


wrote:


Hi All,



 Please review this change for updating libjpeg7 to
libjpeg9c.



 Webrev:
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ 
->

Complete patch with changes in make files and Netbeans project files.

 Webrev:
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/ 

->  Partial patch, updated 9c files in earlier libjpeg7 folder for 
ease to

go through difference.



 JBS: https://bugs.openjdk.java.net/browse/JDK-8203884



Regards,

Ambarish

Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c

[Phil Race]

On 10/1/2018 1:55 PM, Phil Race wrote:

The JDK has shipped a libjpeg since, well, forever.


PS .. we now call it libjavajpeg.so but that is recent (JDK 9).

-phil.


For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.

The JDK approach used to be tediously maintained mapfiles. But 
recently it
was switched to use compiler directives. The default for such a 
library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to 
touch
the imported source files, just add the JNIEXPORT directive to the 
declarations of
the JNI functions in the JDK's own source files which are compiled 
into the library.

And of course some makefile work.

See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html

We can do something like this for FX in a follow-on bug

Another follow-on bug opportunity, is for FX to do what JDK 11 does, 
which
is to defer to the system libjpeg on Linux (and Solaris, but not 
relevant to FX).

So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.

-phil.

On 10/01/2018 10:59 AM, Johan Vos wrote:
Unrelated to the patch, I wonder if there is a better way to include 
this

functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, 
where

we build a static executable).

Is it an option to prefix the public symbols?

- Johan


On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte 


wrote:


Hi All,



 Please review this change for updating libjpeg7 to
libjpeg9c.



 Webrev:
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/ ->
Complete patch with changes in make files and Netbeans project files.

 Webrev:
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/ 

->  Partial patch, updated 9c files in earlier libjpeg7 folder for 
ease to

go through difference.



 JBS: https://bugs.openjdk.java.net/browse/JDK-8203884



Regards,

Ambarish

Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c

[Phil Race]

The JDK has shipped a libjpeg since, well, forever.
For a long time it did export all the symbols, but what is now probably
an even longer time, it has exported only the JNI entry points.
We can do the same here.

The JDK approach used to be tediously maintained mapfiles. But recently it
was switched to use compiler directives. The default for such a library as
libjavafx_iio.so is that symbols aren't exported, and we don't need to touch
the imported source files, just add the JNIEXPORT directive to the 
declarations of
the JNI functions in the JDK's own source files which are compiled into 
the library.

And of course some makefile work.

See https://bugs.openjdk.java.net/browse/JDK-8200178 and
http://mail.openjdk.java.net/pipermail/build-dev/2018-March/021306.html

We can do something like this for FX in a follow-on bug

Another follow-on bug opportunity, is for FX to do what JDK 11 does, which
is to defer to the system libjpeg on Linux (and Solaris, but not 
relevant to FX).

So libjavafx_iio.so on Linux would become just a small entry point to the
platform JPEG library.

-phil.

On 10/01/2018 10:59 AM, Johan Vos wrote:

Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).

Is it an option to prefix the public symbols?

- Johan


On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte 
wrote:


Hi All,



 Please review this change for updating libjpeg7 to
libjpeg9c.



 Webrev:
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/  ->
Complete patch with changes in make files and Netbeans project files.

 Webrev:
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
->  Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
go through difference.



 JBS: https://bugs.openjdk.java.net/browse/JDK-8203884



Regards,

Ambarish

Re: Setting the FreeType LCD filter

[Phil Race]

I think I can re-open https://bugs.openjdk.java.net/browse/JDK-8188810
The submitter there is comparing windows to Linux so there are many
things that are different, but the fringing in the Linux examples are
enough to make it possible that this was the real issue there.

-phil.


On 09/30/2018 02:03 PM, Philip Race wrote:

Hi,

Your explanation makes sense.
Compile time linking is probably best so long as we can verify that
the function is available on all the platforms we need to build & run 
on .. notably

older versions of OEL

Failing that, then as well as adding ".6" we should initialise

    jint rc =-1;

instead of to zero .. so that failure to find the function isn't confused
as failure *of* the function, which in a nutshell, seems to be the bug 
here.
And I suppose we have the same bug on "older" systems where the 
freetype library is

found but lack the symbol.

Is there no JBS bug id already open on this ? If one was closed as not 
reproducible,

we can re-open it. Better than creating a new one.

-phil.

On 9/30/18, 12:03 PM, John Neffenger wrote:
I think I found the cause of the text rendering problem I have always 
seen in JavaFX applications on Linux:


Reduce color fringes in FreeType subpixel rendering
https://github.com/javafxports/openjdk-jfx/issues/229

I'm finally seeing the fonts as they were intended! I used the Oracle 
bug report outline as a template for the GitHub issue to make it easy 
to copy to the Java Bug Database. Do I need a Java Bug ID before I 
submit a pull request?


Thanks,
John

P.S.: For background information, there is a great demonstration of 
LCD filtering algorithms by Felipe Heidrich at 1:02:47 into the video 
"JavaFX Text Rendering" . The 
link takes you directly to the two-minute segment showing the text 
rendered by FreeType, first with no filter, and then with its various 
filter options. (Note: the audio is a bit loud.)

Re: [12] RFR : JDK-8203884 : Update libjpeg to version 9c

[Johan Vos]

Unrelated to the patch, I wonder if there is a better way to include this
functionality.
If we bundle an application that uses JavaFX but also includes a native
library that links with libjpeg, there will be issues due to duplicate
symbols (this happens for example when running deeplearning4j on ios, where
we build a static executable).

Is it an option to prefix the public symbols?

- Johan


On Mon, Oct 1, 2018 at 5:59 PM Ambarish Rapte 
wrote:

> Hi All,
>
>
>
> Please review this change for updating libjpeg7 to
> libjpeg9c.
>
>
>
> Webrev:
> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/  ->
> Complete patch with changes in make files and Netbeans project files.
>
> Webrev:
> http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/
> ->  Partial patch, updated 9c files in earlier libjpeg7 folder for ease to
> go through difference.
>
>
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8203884
>
>
>
> Regards,
>
> Ambarish
>

[12] RFR : JDK-8203884 : Update libjpeg to version 9c

[Ambarish Rapte]

Hi All,

 

Please review this change for updating libjpeg7 to libjpeg9c.

 

Webrev: 
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_for_checkin/  -> 
Complete patch with changes in make files and Netbeans project files.

Webrev: 
http://cr.openjdk.java.net/~arapte/fx/8203884/webrev.00_diff_with_libjpeg7/  -> 
 Partial patch, updated 9c files in earlier libjpeg7 folder for ease to go 
through difference.

 

JBS: https://bugs.openjdk.java.net/browse/JDK-8203884

 

Regards,

Ambarish

Re: State of maven artifacts

[Johan Vos]

Hi,

Have a look at the sample (maven/gradle) in
https://openjfx.io/openjfx-docs/

For maven, a pom.xml without any classifier is needed. This is because the
javafx module pom files have a javafx.pom as a parent, that will test the
current OS, and then use that as a classifier to download the correct
versions of the artifacts.

For gradle, the classifier needs to be in the build.gradle (e.g. see
https://openjfx.io/openjfx-docs/build.gradle) The logic in the sample shows
that the classifier can be detected though in the build.gradle.

- Johan


Op ma 1 okt. 2018 om 12:54 schreef Nir Lisker :

> Well, whatever the case is, it needs to be tested and documented. If we
> don't have that, we can't expect developers to use the library.
>
> I can run a series of tests with both Maven and Gradle (on Win10 with
> Eclipse).
>
> - Nir
>
> On Mon, Oct 1, 2018 at 12:43 PM Scott Palmer  wrote:
>
> > I stopped using Maven years ago after switching to Gradle. So that could
> > be right.  I think there was an issue with Gradle processing transitive
> > dependencies with a classifier or something.  Thankfully Gradle makes it
> > easy to specify the right classifier.
> >
> > Scott
> >
> >
> > > On Sep 30, 2018, at 7:01 PM, Michael Ennen 
> wrote:
> > >
> > > Scott,
> > >
> > > It seems that, for me at least, specifying the platform manually is not
> > necessary on
> > > Maven but is necessary on Gradle. Looking at the POMs themselves it
> > seems that
> > > the javafx-graphics, javafx-controls, etc. modules declare a dependency
> > on the
> > > platform specific artifacts:
> > >
> > > 
> > > org.openjfx
> > > javafx-base
> > > 11
> > > ${javafx.platform}
> > > 
> > >
> > > and declare as their parent:
> > >
> > > 
> > > org.openjfx
> > > javafx
> > > 11
> > > 
> > >
> > > and the POM for that parent has the platform-specific Maven profiles
> > built-in.
> > >
> > > So in other words the logic is already built in to the Maven POM and
> > therefore
> > > works out of the box with Maven but Gradle does not re-use the Maven
> > profile
> > > logic in the POM.
> > >
> > > Regards,
> > > Michael Ennen
> > >
> > > On Sun, Sep 30, 2018 at 2:19 PM Scott Palmer  > > wrote:
> > > I thought he was saying the exact opposite.
> > > You must specify the platform by using some mechanism in Maven
> > (profiles?) or Gradle.
> > >
> > > That’s what worked for me anyway.
> > >
> > > Scott
> > >
> > > > On Sep 26, 2018, at 6:19 AM, Michael Ennen  > > wrote:
> > > >
> > > > And just to reiterate and confirm for anyone trying to get a handle
> on
> > using
> > > > the Maven artifacts - it is *NOT* necessary to manually specify the
> > platform
> > > > classifier when using maven or gradle (nor add the automatic tricks
> to
> > your
> > > > own project) because the JavaFX artifacts will automatically detect
> the
> > > > platform you are building on and pull in the correct artifacts,
> right?
> > > >
> > > > Thanks for your work in this area Johan.
> > > >
> > > > On Wed, Sep 26, 2018 at 12:31 AM Johan Vos   > jo...@lodgon.com>> wrote:
> > > >
> > > >> The problem with that is that there is no cross-platform version of
> > the
> > > >> jars itself. The windows-jar for the graphics module contains
> > different
> > > >> Java classes than the linux jar, for example.
> > > >> The top-level API's are the same of course, hence the logical Java
> > module
> > > >> is the same, but different physical jars are really needed.
> > > >> I realise this may be strange at compile time, where you only care
> > about
> > > >> the top-level API's. Therefore, people added nice "tricks" to both a
> > > >> pom.xml and build.gradle system to automatically detect the current
> > (host)
> > > >> operating system, and making sure the correct artifacts are then
> used.
> > > >>
> > > >> What I really wanted to avoid is that developers had to manually add
> > their
> > > >> platform (e.g. "win") in the build files, as this would break
> > > >> cross-platform development (imagine you're in a team with a win and
> a
> > linux
> > > >> user, and they constantly change the pom.xml or build.gradle file
> for
> > > >> this...).
> > > >>
> > > >> I think the current solution deals pretty well with the current
> > situations,
> > > >> where there are different concepts in gradle/maven/sonatype and in
> > the Java
> > > >> module system.
> > > >>
> > > >> - Johan
> > > >>
> > > >>
> > > >>
> > > >> Op wo 26 sep. 2018 om 05:46 schreef Nir Lisker  > >:
> > > >>
> > > >>> Thanks Sam, that solved it. For some reason I was thinking that if
> > you
> > > >>> don't specify the platform it downloads a version with all native
> > > >>> dependencies for cross compilation.
> > > >>>
> > > >>> On Wed, Sep 26, 2018 at 2:37 AM Sam Carlberg <
> sam.carlb...@gmail.com
> > >
> > > >>> wrote:
> > > >>>
> > >  The libraries are in artifacts with