Re: sane default option values for Linux

[Philip Race]

Some of the latest Linuxes don't even include GTK2 by default !
Its only a step away from them not being even available as an optional 
download.


> ...although I honestly don't think this was a regression introduced 
in JavaFX...
> literally every graphical application segfaults now, including games 
like Minecraft..


Since Minecraft does not use Swing, Java2D, AWT or JavaFx *at all* - not 
even loading them - it
definitely there can't be anything in the Java client stack that is 
causing it.
So if switching to GTK2 miraculously cures it, then that seems like a 
coincidence
and not anything we are doing. It could be a change elsewhere in the 
JDK, if it
reproduces today with 12+ but not 11, but bringing it up on this list, 
or requesting

this workaround, both seem to be pointing in the wrong direction.
And Kevin's suggestion of a driver bug seems possible + worth looking into.

-phl

On 3/18/20, 5:04 AM, Kevin Rushforth wrote:


> Regardless, the other issues are still valid. Can we please have 
GTK2 set as default along with force painter uploading?


No, we are not going to do this. GTK 2 is on its way out. GTK 3 has 
been the default for both AWT and JavaFX since JDK 11 / JavaFX 11. I'd 
much rather see energy going into fixing any remaining GTK 3 issues 
than take a step backwards.


The other issues you are seeing relating to the need for 
"forceUploadingPainter" and the crash in libnvidia-glcore are 
indicative of a possible graphics driver bug. We do plenty of testing 
on Linux and haven't see reports of the problems you are having. The 
likely solution would be to blacklist that driver and fall back to the 
software pipeline. You might consider "-Dprism.order=sw" rather than 
using forceUploadingPainter (the latter is only intended for testing 
and not recommended for production).


-- Kevin


On 3/18/2020 12:48 AM, Ty Young wrote:
After going through varies JDK versions from OpenJDK from 8 to 
present, it seems like the segfault issues was introduced elsewhere 
at about JDK12/13.



Regardless, the other issues are still valid. Can we please have GTK2 
set as default along with force painter uploading?



On 3/17/20 6:54 AM, Ty Young wrote:

Hi all,


After many months of being unable to run my JavaFX application due 
to transitioning to the new Project Panama MemoryAccess API(for 
native C calling, of course), I've finally gotten things to 
semi-working order and able to tryout JavaFX 14... only to find out 
that JavaFX on Linux is still buggy without specifying runtime args.



To recap for those who don't develop JavaFX on Linux or use it, if 
you don't have -Dprism.forceUploadingPainter=true set, JavaFX 
applications will suffer from buffer zeroing when resizing an 
application. This affects *ALL* JavaFX applications. There are still 
GTK3 bugs and regressions that, since it was enabled by default back 
in JavaFX 11(IIRC) still haven't been fixed. If you try to use GTK3 
right now with JavaFX 14 you get a GDK warning:



(java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or 
taller than 32767 pixels are not supported



This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. 
No application code requests a window that tall or wide.



As a bonus, something new that was introduced in Java 13(12?) and 
later is that exiting a JavaFX application will cause a segfault:



# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fbfbad22d9d, pid=68034, tid=68044
#
# JRE version: OpenJDK Runtime Environment (15.0) (build 
15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew)
# Java VM: OpenJDK 64-Bit Server VM 
(15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed 
mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)

# Problematic frame:
# C  [libnvidia-glcore.so.440.64+0xa95d9d]


...although I honestly don't think this was a regression introduced 
in JavaFX... literally every graphical application segfaults now, 
including games like Minecraft... but regardless it happens when 
exiting a JavaFX application too. Originally I thought it was a bug 
caused by the Project Panama builds but it's been persistent for 
over a year now. I'm guessing something broke in JDK proper.



Anyway, point of this email isn't to complain that no one is testing 
JavaFX on Linux(clearly no one is, by the by), but to ask why sane 
defaults aren't being used. Anyone developing a JavaFX application 
on and/or for Linux(god help them) is not going to know how to fix 
problems caused by GTK3 or by not forcing painter uploading, so, if 
no one is going to fix these issues(which is fine, I guess), why not 
use config options that are known to work properly?

RFR: 8089134: [2D traversal, RTL] TraversalEngine only handles left/right key traversal correctly in RTL for top-level engine in ToolBar

[Ajit Ghaisas]

**Issue**
https://bugs.openjdk.java.net/browse/JDK-8089134

**Fix**
Added a fix to modify selection direction based on NodeOrientation of the 
ToolBar.

**Testing**
Added a unit test to test common focus movement scenarios using tab and arrow 
keys for the ToolBar.

-

Commit messages:
 - whitespace_removal
 - toolbar_rtl_focus_fix

Changes: https://git.openjdk.java.net/jfx/pull/144/files
 Webrev: https://webrevs.openjdk.java.net/jfx/144/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8089134
  Stats: 348 lines in 2 files changed: 348 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/144.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/144/head:pull/144

PR: https://git.openjdk.java.net/jfx/pull/144

Re: Raspberry Pi 4 hw support

[Debayan Sutradhar]

Ok, thanks for the clarification. Will be waiting. You all are doing a
really great job.

This looks really promising. JavaFX is getting the love it actually
deserved.

On Wed, 18 Mar 2020 at 6:26 PM, Johan Vos  wrote:

> Hi,
>
> The later Raspian distributions are using new drivers that require
> different configurations to be used with HW acceleration.
> The JavaFX ARM builds are dependent on a specific set of libraries. We'll
> have to document this better.
>
> - Johan
>
> On Mon, Mar 9, 2020 at 8:50 AM Debayan Sutradhar <
> debayansutradh...@gmail.com> wrote:
>
>> I have a large embedded project for raspberry pis (https://stream-pi.com)
>> and recently its discord server crosses 60 members and growing every
>> month.
>> Unfortunately it seems that Hardware acceleration doesnt work on VideoCore
>> VI.
>>
>> If es2 pipeline is used, the program exits after the output "* failed to
>> add service - already in use?"
>>
>> Hence for now we are using sw pipeline to use javafx apps. That makes them
>> very slow and touch gestures don't work as expect.
>>
>> Regards,
>> Debayan Sutradhar
>>
>

Re: [Rev 03] RFR: 8217472: Add attenuation for PointLight

[Nir Lisker]

On Tue, 17 Mar 2020 02:50:28 GMT, Nir Lisker  wrote:

>> Updated test case: 
>> [attenTest2.zip](https://github.com/openjdk/jfx/files/4332937/attenTest2.zip)
>
> On Win 10 with an AMD RX 470 4GB I get the following:
> 
> Without the patch:
> 200 quads average 113 fps
> 5000 quads average 11.5 fps
> 
> With the patch:
> 200 quads average 106 fps fps
> 5000 quads average 8.5 fps
> 
> Will test on Ubuntu later.

On Ubuntu 18 with an AMD RX 470 4GB I get the following:

Without the patch:
200 quads average 107 fps
5000 quads average 11.5 fps

With the patch:
200 quads average 107 fps fps
5000 quads average 11 fps

-

PR: https://git.openjdk.java.net/jfx/pull/43

Re: Raspberry Pi 4 hw support

[Johan Vos]

Hi,

The later Raspian distributions are using new drivers that require
different configurations to be used with HW acceleration.
The JavaFX ARM builds are dependent on a specific set of libraries. We'll
have to document this better.

- Johan

On Mon, Mar 9, 2020 at 8:50 AM Debayan Sutradhar <
debayansutradh...@gmail.com> wrote:

> I have a large embedded project for raspberry pis (https://stream-pi.com)
> and recently its discord server crosses 60 members and growing every month.
> Unfortunately it seems that Hardware acceleration doesnt work on VideoCore
> VI.
>
> If es2 pipeline is used, the program exits after the output "* failed to
> add service - already in use?"
>
> Hence for now we are using sw pipeline to use javafx apps. That makes them
> very slow and touch gestures don't work as expect.
>
> Regards,
> Debayan Sutradhar
>

Re: Bulk request to backport 21 fixes to 11-dev for 11.0.7

[Johan Vos]

Approved.

On Wed, Mar 18, 2020 at 1:03 AM Kevin Rushforth 
wrote:

> Hi Johan,
>
> We request approval to backport the following 21 fixes, which Guru and I
> prepared. Two of the 21 fixes, the GStreamer and Glib upgrades, were done
> as a single commit, so there will be a single changeset pushed for those
> two. By coincidence, that commit is the only one that didn't apply cleanly
> due to a minor merge conflict in one file as a result of an earlier fix (I
> had earlier fixed this same conflict in mainline). I uploaded the changeset
> patch with the conflict fixed here if you want to take a look:
>
> http://cr.openjdk.java.net/~kcr/8230610/8230610.patch.zip
>
> All other patches apply cleanly, ignoring the copyright year in one file
> for one of the patches.
>
> Here is the list of bugs
>
> JDK-8222746  -- Cleanup
> third-party legal files
> JDK-8232210  -- Update
> Mesa 3-D Headers to version 19.2.1
> JDK-8233421  -- Upgrade
> to Visual Studio 2017 version 15.9.16
> JDK-8233420  -- Upgrade
> to gcc 8.3 on Linux
> JDK-8231188  -- Update
> SQLite to version 3.30.1
> JDK-8231126  --
> libxslt.md has incorrect version string
> JDK-8234056  -- Upgrade
> to libxslt 1.1.34
> JDK-8234704  -- Fix
> attribution in libxslt.md
> JDK-8230610  -- Upgrade
> GStreamer to version 1.16.1  /   JDK-8230609
>  -- Upgrade glib to
> version 2.62.2
> JDK-8232589  -- Remove
> CoreAudio Utility Classes
> JDK-8233747  -- JVM
> crash in com.sun.webkit.dom.DocumentImpl.createAttribute
> JDK-8233942  -- Update
> to 609.1 version of WebKit
> JDK-8237003  -- Remove
> hardcoded WebAnimationsCSSIntegrationEnabled flag in DumpRenderTree
> JDK-8231513  -- JavaFX
> cause Keystroke Receiving prompt on MacOS 10.15 (Catalina)
> JDK-8238526  -- Cherry
> pick GTK WebKit 2.26.3 changes
> JDK-8239454  --
> LLIntData : invalid opcode returned for 16 and 32 bit wide instructions
> JDK-8239109  -- Update
> SQLite to version 3.31.1
> JDK-8240211  -- Stack
> overflow on Windows 32-bit can lead to crash
> JDK-8240832  -- Remove
> unused applecoreaudio.md third-party legal file
> JDK-8201539  -- Crash
> in DirectWrite CreateBitmap code when running TestFX test suite
>
> Let us know if you have any questions.
>
> -- Kevin
>
>

Re: Raspberry Pi 4 hw support

[Nir Lisker]

I thought that Johan Vos's team did some work on Raspberry, maybe he can
comment on this.

On Mon, Mar 9, 2020 at 9:50 AM Debayan Sutradhar <
debayansutradh...@gmail.com> wrote:

> I have a large embedded project for raspberry pis (https://stream-pi.com)
> and recently its discord server crosses 60 members and growing every month.
> Unfortunately it seems that Hardware acceleration doesnt work on VideoCore
> VI.
>
> If es2 pipeline is used, the program exits after the output "* failed to
> add service - already in use?"
>
> Hence for now we are using sw pipeline to use javafx apps. That makes them
> very slow and touch gestures don't work as expect.
>
> Regards,
> Debayan Sutradhar
>

Re: sane default option values for Linux

[Kevin Rushforth]

> Regardless, the other issues are still valid. Can we please have GTK2 
set as default along with force painter uploading?


No, we are not going to do this. GTK 2 is on its way out. GTK 3 has been 
the default for both AWT and JavaFX since JDK 11 / JavaFX 11. I'd much 
rather see energy going into fixing any remaining GTK 3 issues than take 
a step backwards.


The other issues you are seeing relating to the need for 
"forceUploadingPainter" and the crash in libnvidia-glcore are indicative 
of a possible graphics driver bug. We do plenty of testing on Linux and 
haven't see reports of the problems you are having. The likely solution 
would be to blacklist that driver and fall back to the software 
pipeline. You might consider "-Dprism.order=sw" rather than using 
forceUploadingPainter (the latter is only intended for testing and not 
recommended for production).


-- Kevin


On 3/18/2020 12:48 AM, Ty Young wrote:
After going through varies JDK versions from OpenJDK from 8 to 
present, it seems like the segfault issues was introduced elsewhere at 
about JDK12/13.



Regardless, the other issues are still valid. Can we please have GTK2 
set as default along with force painter uploading?



On 3/17/20 6:54 AM, Ty Young wrote:

Hi all,


After many months of being unable to run my JavaFX application due to 
transitioning to the new Project Panama MemoryAccess API(for native C 
calling, of course), I've finally gotten things to semi-working order 
and able to tryout JavaFX 14... only to find out that JavaFX on Linux 
is still buggy without specifying runtime args.



To recap for those who don't develop JavaFX on Linux or use it, if 
you don't have -Dprism.forceUploadingPainter=true set, JavaFX 
applications will suffer from buffer zeroing when resizing an 
application. This affects *ALL* JavaFX applications. There are still 
GTK3 bugs and regressions that, since it was enabled by default back 
in JavaFX 11(IIRC) still haven't been fixed. If you try to use GTK3 
right now with JavaFX 14 you get a GDK warning:



(java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or 
taller than 32767 pixels are not supported



This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. 
No application code requests a window that tall or wide.



As a bonus, something new that was introduced in Java 13(12?) and 
later is that exiting a JavaFX application will cause a segfault:



# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fbfbad22d9d, pid=68034, tid=68044
#
# JRE version: OpenJDK Runtime Environment (15.0) (build 
15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew)
# Java VM: OpenJDK 64-Bit Server VM 
(15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed 
mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)

# Problematic frame:
# C  [libnvidia-glcore.so.440.64+0xa95d9d]


...although I honestly don't think this was a regression introduced 
in JavaFX... literally every graphical application segfaults now, 
including games like Minecraft... but regardless it happens when 
exiting a JavaFX application too. Originally I thought it was a bug 
caused by the Project Panama builds but it's been persistent for over 
a year now. I'm guessing something broke in JDK proper.



Anyway, point of this email isn't to complain that no one is testing 
JavaFX on Linux(clearly no one is, by the by), but to ask why sane 
defaults aren't being used. Anyone developing a JavaFX application on 
and/or for Linux(god help them) is not going to know how to fix 
problems caused by GTK3 or by not forcing painter uploading, so, if 
no one is going to fix these issues(which is fine, I guess), why not 
use config options that are known to work properly?

Re: RFR: 8236651: Simplify and update glass gtk backend

[Thiago Milczarek Sayao]

On Tue, 3 Mar 2020 11:10:07 GMT, Thiago Milczarek Sayao  
wrote:

>> This is going to need further discussion on the mailing list as indicated 
>> above, so it is still premature to review it
>> (i.e., it should still be considered effectively a "WIP" until that 
>> discussion happens). Additionally, this is a
>> significant and risky change, so I'd like additional eyes on it when we do 
>> get to the point of reviewing it.
>
> I have been testing this for several days on ubuntu 18.04 and it's working 
> good. It pass system tests, runs Ensemble 8
> and Scenebuilder.
> Will have to do some tests on 16.04.

Results with Ubuntu **16.04**

![image](https://user-images.githubusercontent.com/30704286/76957765-2ed1d080-68f5-11ea-88c4-9d81528f792e.png)

Will look into test.javafx.stage.DeiconifiedWithChildTest and 
test.robot.javafx.scene.layout.RegionBackgroundFillUITest.

I've used a VM, so might be related.

Also ran Ensemble8 and the Drag and Drop test app with no apparent issues.

-

PR: https://git.openjdk.java.net/jfx/pull/77

Re: sane default option values for Linux

[Ty Young]

After going through varies JDK versions from OpenJDK from 8 to present, 
it seems like the segfault issues was introduced elsewhere at about 
JDK12/13.



Regardless, the other issues are still valid. Can we please have GTK2 
set as default along with force painter uploading?



On 3/17/20 6:54 AM, Ty Young wrote:

Hi all,


After many months of being unable to run my JavaFX application due to 
transitioning to the new Project Panama MemoryAccess API(for native C 
calling, of course), I've finally gotten things to semi-working order 
and able to tryout JavaFX 14... only to find out that JavaFX on Linux 
is still buggy without specifying runtime args.



To recap for those who don't develop JavaFX on Linux or use it, if you 
don't have -Dprism.forceUploadingPainter=true set, JavaFX applications 
will suffer from buffer zeroing when resizing an application. This 
affects *ALL* JavaFX applications. There are still GTK3 bugs and 
regressions that, since it was enabled by default back in JavaFX 
11(IIRC) still haven't been fixed. If you try to use GTK3 right now 
with JavaFX 14 you get a GDK warning:



(java:64002): Gdk-WARNING **: 06:23:04.022: Native Windows wider or 
taller than 32767 pixels are not supported



This is not so if GTK 2 is specified by doing: -Djdk.gtk.version=2. No 
application code requests a window that tall or wide.



As a bonus, something new that was introduced in Java 13(12?) and 
later is that exiting a JavaFX application will cause a segfault:



# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x7fbfbad22d9d, pid=68034, tid=68044
#
# JRE version: OpenJDK Runtime Environment (15.0) (build 
15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew)
# Java VM: OpenJDK 64-Bit Server VM 
(15-internal+0-adhoc.ty.panama-foreign-foreign-jextractnew, mixed 
mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)

# Problematic frame:
# C  [libnvidia-glcore.so.440.64+0xa95d9d]


...although I honestly don't think this was a regression introduced in 
JavaFX... literally every graphical application segfaults now, 
including games like Minecraft... but regardless it happens when 
exiting a JavaFX application too. Originally I thought it was a bug 
caused by the Project Panama builds but it's been persistent for over 
a year now. I'm guessing something broke in JDK proper.



Anyway, point of this email isn't to complain that no one is testing 
JavaFX on Linux(clearly no one is, by the by), but to ask why sane 
defaults aren't being used. Anyone developing a JavaFX application on 
and/or for Linux(god help them) is not going to know how to fix 
problems caused by GTK3 or by not forcing painter uploading, so, if no 
one is going to fix these issues(which is fine, I guess), why not use 
config options that are known to work properly?

Re: [Integrated] RFR: 8239107: Update libjpeg to version 9d

[Ambarish Rapte]

Changeset: 90289a23
Author:Ambarish Rapte 
Date:  2020-03-18 05:57:46 +
URL:   https://git.openjdk.java.net/jfx/commit/90289a23

8239107: Update libjpeg to version 9d

Reviewed-by: kcr, ajoseph

! modules/javafx.graphics/src/main/legal/jpeg_fx.md
! modules/javafx.graphics/src/main/native-iio/libjpeg/README
! modules/javafx.graphics/src/main/native-iio/libjpeg/UPDATING.txt
! modules/javafx.graphics/src/main/native-iio/libjpeg/jccolor.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jchuff.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jcinit.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jcmarker.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jcmaster.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jcomapi.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jcparam.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdcolor.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdct.h
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdhuff.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdmarker.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdmaster.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdmerge.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jdtrans.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jerror.h
! modules/javafx.graphics/src/main/native-iio/libjpeg/jfdctint.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jidctint.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jmemmgr.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jmemnobs.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jpegint.h
! modules/javafx.graphics/src/main/native-iio/libjpeg/jpeglib.h
! modules/javafx.graphics/src/main/native-iio/libjpeg/jutils.c
! modules/javafx.graphics/src/main/native-iio/libjpeg/jversion.h