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