brcolow
commented
5 years ago @pyokagan Are you still intending on opening a PR?
Closed brcolow closed 5 years ago
brcolow
commented
5 years ago @pyokagan Are you still intending on opening a PR?
pyokagan
commented
5 years ago @brcolow I was hoping that there would be some discussion on https://github.com/javafxports/openjdk-jfx/issues/66#issuecomment-453584032 :-/ (On whether it might be safe to replace all calls to PrismFontFactory.getFactory() with GraphicsPipeline.getFactory())
If there is no consensus on that I might try another approach that involves adding "GraphicsPipeline shutdown hooks" that are called when the GraphicsPipeline is disposed.
In the meantime, I can submit the "native approach" as a PR since I already had that done.
brcolow
commented
5 years ago I personally think the native solution makes the most sense - why involve Java at all when it comes to COM shutdown?
kevinrushforth
commented
5 years ago A Java disposer solution is generally what we use to clean up resources (of all kinds), many of which need to run on the graphics thread. I suppose one thing that makes this different is that we want to clean up only on shutdown, and there isn't a good place to do this at the moment.
So, I would prefer a more general disposer solution, although we could evaluate a proposed fix based on the native solution.
As a reminder, though, we need a contributor agreement on file. Please read CONTRIBUTING.md for what you need to do.
To answer the following question:
I was hoping that there would be some discussion on #66 (comment) :-/ (On whether it might be safe to replace all calls to PrismFontFactory.getFactory() with GraphicsPipeline.getFactory())
No, this does not seem like a good plan.
If there is no consensus on that I might try another approach that involves adding "GraphicsPipeline shutdown hooks" that are called when the GraphicsPipeline is disposed.
That's more in line with what I was thinking.
kevinrushforth
commented
5 years ago As a reminder, though, we need a contributor agreement on file.
I see that the OCA for @pyokagan is already recorded.
pyokagan
commented
5 years ago @kevinrushforth
That's more in line with what I was thinking.
Thanks, I'll try exploring this approach.
JanMosigItemis
commented
5 years ago Keep up the good work guys! 👍 I also recently encountered this issue on Windows 10 + JDK 11.0.2. Is there a workaround for this except from disabling headless mode?
brcolow
commented
5 years ago No workaround that I know of - I don't think it is possible to workaround this except for as you noted disabling headless mode.
meszarv
commented
5 years ago as a temporary workaround I was able to prevent the jvm crash by calling
System.load("C:\\Windows\\System32\\WindowsCodecs.dll");
before javafx initializes.
JanMosigItemis
commented
5 years ago I can approve, that the workaround @meszarv mentioned actually works. Only problem is: You need to really run it before any FxToolkit code, which will most likely require static initialization blocks in many cases and clever class loading prediction.
I would test the fix kindly provided by @kevinrushforth but unfortunately it has not been released yet.
kevinrushforth
commented
5 years ago The fix will be in the next early access build of JavaFX 13 (build 2).
After adding a Java 10 build to our (TestFX) appveyor configuration, I am seeing a crash (every time at the same place):
https://ci.appveyor.com/project/testfx/testfx/build/master%201046/job/3pl22fioi0ut9juc#L492
It is triggered by this test.
I believe it is crashing in modules/javafx.graphics/src/main/native-font/directwrite.cpp in the
JNIEXPORT jlong JNICALL OS_NATIVE(CreateBitmap)method. This is somewhat strange because that file hasn't been modified since the javafx-font and javafx-font-native modules were open sourced (as RT-31139) so figuring out why this would precipitate a crash now in Java 10 is probably non-trivial.Here is the crash dump: