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=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?
>>