sane default option values for Linux

Ty Young youngty1997 at gmail.com
Tue Mar 17 11:54:52 UTC 2020


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=0x00007fbfbad22d9d, 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?



More information about the openjfx-dev mailing list