Re: Javafx 17 and moditect no longer working
My application also does not work with 17. The module-info.java spits out random duplicate module reading errors and JavaFX classes can't be found at compile time. On 9/10/21 5:47 AM, Clemens Lanthaler wrote: Hello everyone, I have just updated from javafx 17-ea+14 to the GA release and I am not able to build one of my projects (PhotoSlide, librawFX, JeditFX, ...) anymore. The root cause is that via maven the it downloads for each component two files (e.g. javafx-base.jar nad javafx-base-mac.jar). The first one contains only the MANIFEST file and nothing more. The problem I have is that until ea+14 the MANIFEST file contained to automatic-module-name and therefore moditect or similar tools can pick this name up. Now the automatic module name is missing in this MANIFEST file and therefore moditect is no finding any module naming anymore and try to use the file name instatt. The problem is that this results in a module name "javafx.base" which is also defined in module-info.class inside of javafx-base-mac.jar. In this case moditect cannot proceed because of duplicate items. Question from my side: Why is this extra jar file necessary ? If it is necessary is there a possability to get back the automatic-module-nam entry in the MANIFEST file ? cheers, Clemens
Re: Enhancements for JavaFX 18
Oh, and to add one more feature: ability to add context menu to specific TreeView cells without going through cell factory. On 7/30/21 7:56 AM, Kevin Rushforth wrote: Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. Specifically, I'd like to see the following proceed: * Transparent backgrounds in WebView JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 PR: https://github.com/openjdk/jfx/pull/563 * Add DirectionalLight JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 PR: https://github.com/openjdk/jfx/pull/548 * CSS pseudoclasses :focus-visible and :focus-within https://bugs.openjdk.java.net/browse/JDK-8268225 PR: https://github.com/openjdk/jfx/pull/475 * Improve property system to facilitate correct usage (minus the binary incompatible API change) JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 PR: https://github.com/openjdk/jfx/pull/590 (Draft) And maybe the following: * Add CSS themes as a first-class concept (need a consensus on how to proceed) * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) There are probably others I'm forgetting. Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. -- Kevin
Re: Enhancements for JavaFX 18
On 8/4/21 5:35 PM, John Hendrikx wrote: On 04/08/2021 19:05, Ty Young wrote: * A late "showing" property for when the application has been shown to the user and all first viewing UI components have had their sizes calculated and are being displayed, if it doesn't exist already and I'm completely blind. Do you mean a property that is true if the current node is visible, attached to a scene which is attached to a window which is currently showing? This can be achieved with a small util that takes a Node and returns an ObservableValue. I can dig up the code, I use this all the time to automatically unbind bindings when UI parts become invisible. Something like that, yes. --John
Re: Enhancements for JavaFX 18
You want a list of bugs that could be fixed? Today's your lucky day! * Resizing a JavaFX window under Linux (still) causes graphical glitches, needing -Dprism.forceUploadingPainter=true or, IIRC, software rendering to "fix". * Resizing ALSO causes graphical glitching on the bottom and right sides on both Windows AND Linux. * Resizing an app with a TableView in view results in the TableView's integrated scrollbars flickering in and out of existence when there is plenty of space left. The less UI content there is, the less this is likely to happen - but it absolutely does happen with *just* a TableView as the root node, you gotta play with it. * Resizing the application from the left causes UI jitter. * JavaFX in general seems to have trouble keeping up with user resizing. Rapidly resizing an application with a DividerPane(TreeView left, content right) results in inconsistent positioning than if it was done slowly, in the very least. * Alt tabbing with a UI component being selected(Slider thumb, scrollbar) results in that component's color being stuck in whatever color is the CSS selected state. * You can middle and right click drag a slider thumb and scroll bars, which does not trigger a CSS state change, which is not consistent with MenuBar items. * JavaFX does not seem to calculate the size of a GridPane or TilePane with elements correctly. This results in content in ScrollPanes that is clearly larger in height than the viewport but ScrollPane does not show its scrollbars - only mouse wheel works without forcing the scrollbars to always show or transition state bugs when putting a GridPane/TilePane inside a TitlePane(or maybe it's TilePane -> TitlePane -> TilePane that's the issue? No clue.) * XY Chart data that is off screen (-1, -1) has lines drawn to them despite being... off screen. Bug or feature? * Setting the Y axis side to Side.RIGHT causes a white space with custom CSS: https://imgur.com/a/4P1Oj1Q. Might be missing some. A few features, while I'm here: * API property to force a TableView's height to be the exact amount needed to display its headers and all its rows. * API to disable TableView's scrollbars completely. * A late "showing" property for when the application has been shown to the user and all first viewing UI components have had their sizes calculated and are being displayed, if it doesn't exist already and I'm completely blind. On 7/30/21 7:56 AM, Kevin Rushforth wrote: Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and enhancement requests for JavaFX 18. It's the summer, so there may be delays as some people are out at various times (including me), but I would like to get some of the outstanding enhancement requests moving over the next few weeks. Specifically, I'd like to see the following proceed: * Transparent backgrounds in WebView JBS: https://bugs.openjdk.java.net/browse/JDK-8090547 PR: https://github.com/openjdk/jfx/pull/563 * Add DirectionalLight JBS: https://bugs.openjdk.java.net/browse/JDK-8234921 PR: https://github.com/openjdk/jfx/pull/548 * CSS pseudoclasses :focus-visible and :focus-within https://bugs.openjdk.java.net/browse/JDK-8268225 PR: https://github.com/openjdk/jfx/pull/475 * Improve property system to facilitate correct usage (minus the binary incompatible API change) JBS: https://bugs.openjdk.java.net/browse/JDK-8268642 PR: https://github.com/openjdk/jfx/pull/590 (Draft) And maybe the following: * Add CSS themes as a first-class concept (need a consensus on how to proceed) * Undecorated interactive stage style (still in early discussion, but the concept looks interesting and useful) There are probably others I'm forgetting. Each of the above should be discussed in their own thread on openjfx-dev rather than a reply to this thread. -- Kevin
Re: Integrated: 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later
Does this also fix the free(): invalid pointer issue when closing a JavaFX application on Linux or is that unrelated? On 7/1/21 6:17 AM, Kevin Rushforth wrote: On Tue, 22 Jun 2021 20:42:48 GMT, Kevin Rushforth wrote: This is a fix for the assertion error message that is printed to the console on macOS 10.15 or later when an application calls `Platform.exit` while a `Stage` is showing. The root cause is a latent bug in the JavaFX glass code that was revealed by an apparent change of behavior in macOS. A few of the object deallocation methods, which are called by the Objective C auto-release mechanism, use the standard `GET_MAIN_JENV` macro to get the JNI environment. The macro will print an assertion warning if Java has been detached. I instrumented the code and can see that `GlassViewDelegate::dealloc` is now called after the `GlassApplication` main loop has detached Java. Since we don't control when the dealloc method is called, it is not correct to do the assertion check in those cases. Some of the dealloc methods already skip this assertion check by grabbing the jEnv pointer directly, so we need to fix the others. I added a new variant of the macro called `GET_MAIN_JENV_NOWARN` with a comment indicating that is suitable for use by the dealloc methods. In addition to verifying that the test program attached to JBS now exits cleanly with no assertion failure message, I added an automated system test that fails on macOS before the fix and passes after the fix. On other platforms it passes already. This pull request has now been integrated. Changeset: 6403d674 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/6403d6745578887b7f2ccc10ac02e7cdd04d09c1 Stats: 208 lines in 7 files changed: 204 ins; 0 del; 4 mod 8231558: [macos] Platform.exit causes assertion error on macOS 10.15 or later Reviewed-by: pbansal, aghaisas - PR: https://git.openjdk.java.net/jfx/pull/540
Re: Moving src.zip out of the lib directory of the JavaFX SDK
Netbeans no longer defaults to creating Ant based projects unlike years ago & there has been, IIRC, some talk on further retiring support for it and Maven works just fine provided that you use the JavaFX Maven plugin*. Still maybe worth fixing since support isn't completely removed and there may be cases where one might want to download and use a JavaFX SDK dist. * the situation with IDE JavaFX support is complicated due to a project created outside Netbeans not set up with hacks Netbeans needs for green run button but there is an in-IDE option to do javafx:run and intellij needs a custom run action created to do javafx:run AFAIK, but I digress. On 6/14/2021 1:15 PM, Kevin Rushforth wrote: We deliver a set of modular jars in the lib directory of the standalone JavaFX SDK. We also deliver src.zip for use by IDEs into that same directory. If you add the lib directory to your application's module path in your IDE, it will try to load src.zip as if it were a jar file, and will fail. This is a pain point for developers using the SDK. This problem has been raised on the mailing list a couple of times, and I think it's time to fix it. This issue is tracked in JBS by JDK-8258499 [1]. I propose to move the src.zip file from the lib directory to the top directory of the SDK. Alternatively, we could create a new directory for src.zip (either a sibling of lib or sub-directory under lib). However, I think it would be easier to find in the top dir of the SDK, and I don't see the need for a new directory just to hold src.zip. Before I create the PR and the associated CSR, I'd like to hear developer's opinions on this. -- Kevin [1] https://bugs.openjdk.java.net/browse/JDK-8258499
Re: Minimum JDK policy for OpenJFX
On 5/30/21 5:19 PM, John Neffenger wrote: On 5/19/21 1:17 PM, Ty Young wrote: Biggest things for JavaFX that I can think of is jextract, a tool for generating Java headers from a C header, and having all binding code written in Java. JavaFX has been doing its own manual form of Project Panama since 2014. Look for the string "extends C.Structure" in the following two files: https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/MX6Cursor.java https://github.com/openjdk/jfx/blob/master/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/EPDSystem.java In both cases, the technique was used to let JavaFX bypass the header file 'mxcfb.h' from NXP (formerly Freescale). I'm looking forward to replacing those hard-coded offsets with the tools from Project Panama. In fact, I'm hopeful that Project Panama will let me remove all of the native C code from the Monocle EPD platform. Now that you pointed it out, JavaFX uses SecurityManager: https://github.com/openjdk/jfx/blob/5e6d4429159e3fab9ec0aab9720393850d179710/modules/javafx.graphics/src/main/java/com/sun/glass/ui/monocle/C.java#L40 Which is being deprecated. Panama has its own runtime flag to enable native access not tied to SecurityManager. The C class native implementation can be replaced with Panama easily. A MemorySegment can be viewed using a ByteBuffer via: MemorySegment segment = MemorySegment.allocateNative(8, ResourceScope.newImplicitScope()); ByteBuffer buffer = segment.asByteBuffer(); asByteBuffer() doc says it wraps the MemorySegment, so I'm guessing it has a strong reference and memory is freed once the buffer and segment are no longer referenced. If someone wanted to try swapping out JavaFX's native implementation with Panama, this would be a good place to start IMO. John
Re: Minimum JDK policy for OpenJFX
GTK4 was just released not that long ago. I don't know how much(if any at all) code is shared between versions, but having a tool like jextract might be useful for adding support for that. Just a guess. Also, the bindings are different in that, for everything not a primitive in java(except boolean and char), you need to allocate memory and pass the address of the memory to the function(e.g. structs, unions, arrays). You also need to, depending on which ResourceScope is used, explicitly free your memory. And, again, everything is in Java. Maybe the ability to allocate off-heap arrays is useful somehow? Maybe to somehow reduce GC pressure when resizing the application or something? On 5/25/21 3:59 AM, Nir Lisker wrote: I looked at jextract a while back. I got the impression that it's more useful when you need to generate new bindings, at the very least because there are fewer ways to make mistakes. Most of the work on JavaFX has already been done in this area and the mistakes have been found and fixed by now, so is there any substantial value in redoing it with jextract? On Thu, May 20, 2021 at 12:25 AM Ty Young <mailto:youngty1...@gmail.com>> wrote: If you want to learn more about Panama you can read the JEP page: https://openjdk.java.net/jeps/412 <https://openjdk.java.net/jeps/412> You can also join the panama-dev list and ask questions: https://mail.openjdk.java.net/mailman/listinfo/panama-dev <https://mail.openjdk.java.net/mailman/listinfo/panama-dev> Biggest things for JavaFX that I can think of is jextract, a tool for generating Java headers from a C header, and having all binding code written in Java. It may be easier to upgrade to newer GTK versions using Panama as there is no C shim required and the bindings are, again, generated for you. jextract does have issues, one of which is that any binding generated using it are platform-specific even if the library itself is cross-platform. You can make bindings by hand that are cross-platform if you want, though. Speaking of GTK, when is JavaFX going to support GTK4? On 5/18/21 4:42 PM, Nir Lisker wrote: >> there are some advantages in being able to run with the latest JDK LTS >> > One *potential* issue with this approach is that LTS is not defined in > OpenJDK as far as I know. The LTS versions are a business decision of each > distributor. For now, they have all aligned on 8, 11, 17, but nothing > guarantees that this will stay so. What if different vendors LTS different > versions? Suppose that Valhalla and Loom add very attractive features in > JDK 19 (big performance enhancements, leads to big money savings on > hardware, leads to economic incentives to use these, leads to requests to > support these), now vendors can declare JDK 19 as LTS, and what will JavaFX > do? > In OpenJDK all versions are treated equally as it is a spec and not a > business model. Should JavaFX be coupled to business models? Maybe Gluon > has some insights since they give JavaFX LTS support. > > A second point, as Michael Strauß mentioned, is that maybe we should see > what features are going to be delivered in the next versions and judge if > there's something attractive enough for library developers to base our > decision on. Sealed classes from Amber are certainly one of them. Panama > might provide handy features for JavaFX's interfacing with native code, > like Foreign Memory Access, though I didn't look into it in detail. > Valhalla is certainly too far away to consider, and Loom is rather > irrelevant for JavaFX and GUIs in general. > If anyone has insights into relevant upcoming features I'll be happy to > learn. > > - Nir > > On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth mailto:kevin.rushfo...@oracle.com>> > wrote: > >> A very timely question. I was already planning to raise this as a >> discussion after we update our boot JDK to JDK 16 (blocked by the >> in-progress gradle 7 update), which I hope to do later this week. >> >> I think that this is the right time to consider bumping the minimum >> required version to run JavaFX 17 to JDK 16, which would allow us to >> start using APIs and language features from JDK 12 through JDK 16 >> inclusive. >> >> In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In >> practice, though, we don't bump it for each release, as there are some >> advantages in being able to run with the latest JDK LTS. Since JavaFX 17 >> will release at roughly the
Re: Minimum JDK policy for OpenJFX
If you want to learn more about Panama you can read the JEP page: https://openjdk.java.net/jeps/412 You can also join the panama-dev list and ask questions: https://mail.openjdk.java.net/mailman/listinfo/panama-dev Biggest things for JavaFX that I can think of is jextract, a tool for generating Java headers from a C header, and having all binding code written in Java. It may be easier to upgrade to newer GTK versions using Panama as there is no C shim required and the bindings are, again, generated for you. jextract does have issues, one of which is that any binding generated using it are platform-specific even if the library itself is cross-platform. You can make bindings by hand that are cross-platform if you want, though. Speaking of GTK, when is JavaFX going to support GTK4? On 5/18/21 4:42 PM, Nir Lisker wrote: there are some advantages in being able to run with the latest JDK LTS One *potential* issue with this approach is that LTS is not defined in OpenJDK as far as I know. The LTS versions are a business decision of each distributor. For now, they have all aligned on 8, 11, 17, but nothing guarantees that this will stay so. What if different vendors LTS different versions? Suppose that Valhalla and Loom add very attractive features in JDK 19 (big performance enhancements, leads to big money savings on hardware, leads to economic incentives to use these, leads to requests to support these), now vendors can declare JDK 19 as LTS, and what will JavaFX do? In OpenJDK all versions are treated equally as it is a spec and not a business model. Should JavaFX be coupled to business models? Maybe Gluon has some insights since they give JavaFX LTS support. A second point, as Michael Strauß mentioned, is that maybe we should see what features are going to be delivered in the next versions and judge if there's something attractive enough for library developers to base our decision on. Sealed classes from Amber are certainly one of them. Panama might provide handy features for JavaFX's interfacing with native code, like Foreign Memory Access, though I didn't look into it in detail. Valhalla is certainly too far away to consider, and Loom is rather irrelevant for JavaFX and GUIs in general. If anyone has insights into relevant upcoming features I'll be happy to learn. - Nir On Tue, May 18, 2021 at 6:17 PM Kevin Rushforth wrote: A very timely question. I was already planning to raise this as a discussion after we update our boot JDK to JDK 16 (blocked by the in-progress gradle 7 update), which I hope to do later this week. I think that this is the right time to consider bumping the minimum required version to run JavaFX 17 to JDK 16, which would allow us to start using APIs and language features from JDK 12 through JDK 16 inclusive. In general, we only guarantee that JavaFX N runs on JDK N-1 or later. In practice, though, we don't bump it for each release, as there are some advantages in being able to run with the latest JDK LTS. Since JavaFX 17 will release at roughly the same time as JDK 17 LTS, I can't think of a good reason to not update our minimum. Comments? -- Kevin On 5/18/2021 7:59 AM, Michael Strauß wrote: Currently, JDK 11 is required for the latest version of OpenJFX. What is the policy for bumping this requirement? Does it always correspond to the latest JDK LTS release (the next of which will be JDK 17), or is it independent from the release cycle of OpenJDK?
Re: Make javafx.controls open and community-driven
On 2/2/21 8:16 PM, Nir Lisker wrote: Hi Mike, First of all, I would have you consider revisiting your medical observation on the state of JavaFX. If you've read the almost-weekly recurrent threads of "should I use Swing or JavaFX" in r/Java, you'd realize that reports of JavaFX's death are greatly exaggerated. But yes, it is very understaffed. Other than that, there is a discussion list, openjfx-disc...@openjdk.java.net, where you can bring up general community and social media related topics and continue that branch of the discussion there. 1. I also advocated for having JBS more open in the past. I was told that Oracle tried opening JBS for everyone, but it was a big mess. I remember Alan Bateman saying a few years ago in an Ask The Architect session, when he was asked about this, that more than half of the bugs submitted are about OpenGL in Minecraft. These are the things you don't see from the outside. I'm guessing some of those are the OpenGL segfault crash on exit that affects (nearly?) *every* OpenGL based Java application for the last few years, including JavaFX and Minecraft, on Nvidia hardware. I have to clear out my build directory often because of it. As for the OCA, it is a license requirement for all of OpenJDK. The developers here have nothing to do with it. I suspect you will have to take it up with the legal department of Oracle. Good luck :) OCA is more of a symptom of a larger problem IMO: gate keeping. A long time ago I suggested a 1-liner change to JavaFX's build script that would simply place the source zip generated with the JavaFX source build *outside* the lib folder. Generating this zip inside the lib folder caused runtime problems with Ant and Netbeans whenever you designated the entire folder as a lib directory in a project and it didn't make sense anyway. It was rejected, IIRC, because of Oracle's or Gluon's server configuration issues with the change. There were no issues doing a local build that I'm aware of when I tested the change locally. More recently, Oracle decided to break Swing applications that use the GTK L on Arch Linux based distros in JDK 16, was notified of the issue multiple times by multiple people, and AFAIK refused to revert the changes simply because Arch Linux isn't a "supported" distro. AFAIK, it's still not possible to even launch Netbeans on Arch Linux without overriding the L Even more recently, I suggested (and was willing to actually do) what I thought to be reasonable API changes to Project Panama, which I use in my JavaFX application, were rejected because it was decided a year ago behind closed doors discussions that the direction of that API part was already decided. Not only that, but the ability to even have a public discussion was basically shut down. Someone has to be that person to make the decisions in the end, but often times it feels like free outsourcing rather than contributing. One moment it's "You should contribute!" and the next it's "No, I didn't mean contribute *that* way!". Anyway, this is a much larger issue that goes beyond JavaFX and I don't want to derail, I'm just pointing out that not only when someone suggests reasonable changes and fixes or, better yet(by far!), is willing to make those changes, they are denied the ability to do so because of reasons that person could not possibly be aware of.
Re: How to create a fat jar for my JavaFX program?
Don't know anything about fat jars, but you could try this jlink plugin: https://tentackle.org/static-content/sitedocs/tentackle/latest/tentackle-jlink-maven-plugin/jlink-mojo.html It works with non-modular projects as well - everything just gets dumped into a folder and put onto the module path. Just follow the standard Maven jlink guide: https://maven.apache.org/plugins/maven-jlink-plugin/usage.html but use the above plugin instead. I've been using it and it works great. Hope this helps.
Re: RFR: 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread
On 6/25/20 10:56 PM, John Neffenger wrote: Fixes [JDK-8201567](https://bugs.openjdk.java.net/browse/JDK-8201567). - Commit messages: - 8201567: QuantumRenderer modifies buffer in use by JavaFX Application Thread Changes: https://git.openjdk.java.net/jfx/pull/255/files Webrev: https://webrevs.openjdk.java.net/jfx/255/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8201567 Stats: 35 lines in 5 files changed: 29 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/255.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/255/head:pull/255 PR: https://git.openjdk.java.net/jfx/pull/255 Does this fix the years old Linux JavaFX buffer reset bug?
Re: Unable to allocate direct buffer memory
On 5/10/20 3:52 PM, John Hendrikx wrote: They're related. 32767x1137x4 = 149024316. It would help to know what your app might be doing. Although it could be a bug in JavaFX, it seems more likely that a canvas/image or cached group or something is a bit bigger than reasonable. I think I've seen such errors in my app before I restricted maximum sizes of images which were supplied from uncontrolled sources. --John No images are used. The only questionable thing is that TilePane/GridPane is used in order to achieve a more responsive UI. I don't remember this being an issue in earlier versions either.
Re: Unable to allocate direct buffer memory
On 5/7/20 3:44 PM, Kevin Rushforth wrote: This suggests that there might be a memory leak (possibly in uploading painter which I see you are using). Is this easily reproducible? I tried doing software rendering just to see if it made any difference. I don't know if it fixed any of the other issues, but it definitely made things worse. Everytime I resize the application it leaks on-heap memory and eventually hits an OutOfMemory exception. It looks like a bunch of int arrays are being allocated and never released. What the hell?
Missing tick marks on charts
Does anyone know whats going on with this: https://imgur.com/a/g7Ti3Zc It doesn't seem to be a space issue, even the top tick mark is missing on the one chart...
Re: com.sun.javafx vs javafx (with example/request)
On the topic of private APIs that should probably be public... can the performance tracker class be made public too? I'd very much like to know the FPS at which my application is running at.
Re: Unable to allocate direct buffer memory
On 5/7/20 3:44 PM, Kevin Rushforth wrote: This suggests that there might be a memory leak (possibly in uploading painter which I see you are using). Is this easily reproducible? Easily? No. I seem to get either(AKA never both) only after hours of having the application running. Nothing seems to break either, making it very strange. I don't remember getting these exceptions in JavaFX 13, just warnings about texture size(which I think others have reported here too). Although, I should say, I'm using Project Panama's Foreign Memory Access builds and those can corrupt memory if used incorrectly. That said, given that the texture size issue was reported here before in JavaFX 13 and before IIRC, I'm not so sure that is the issue. As for the other exception: java.lang.RuntimeException: Requested texture dimensions (32767x1137) require dimensions (0x1137) that exceed maximum texture size (16384) Are you really trying to draw into a texture that big? If not, then either the error message is printing the wrong sizes (which is quite possible) or else something is causing a larger than expected size to be used. Uh, I use Integer.MAX_VALUE for prefered width/height, not Short.MAX_VALUE. I don't know where 32767(Short.MAX_VALUE) is coming from, I never explicitly request those dimensions. Could the screen being locked and the screen being off have to do with this? -- Kevin On 5/7/2020 11:51 AM, Ty Young wrote: On 5/6/20 12:39 PM, Ty Young wrote: After hours of running my JavaFX application I start getting this error spammed in console: java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct buffer memory (allocated: 149066725, limit: 209715200) at java.base/java.nio.Bits.reserveMemory(Bits.java:178) at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:120) at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329) at javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90) at javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121) at javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155) at javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) Ironically every single error is about allocating the exact same amount of bytes. Anything on this? I'm also getting: java.lang.RuntimeException: Requested texture dimensions (32767x1137) require dimensions (0x1137) that exceed maximum texture size (16384) at javafx.graphics/com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220) at javafx.graphics/com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:165) at javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:124) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) spammed alternatively.
Re: Unable to allocate direct buffer memory
On 5/6/20 12:39 PM, Ty Young wrote: After hours of running my JavaFX application I start getting this error spammed in console: java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct buffer memory (allocated: 149066725, limit: 209715200) at java.base/java.nio.Bits.reserveMemory(Bits.java:178) at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:120) at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329) at javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90) at javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121) at javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155) at javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) Ironically every single error is about allocating the exact same amount of bytes. Anything on this? I'm also getting: java.lang.RuntimeException: Requested texture dimensions (32767x1137) require dimensions (0x1137) that exceed maximum texture size (16384) at javafx.graphics/com.sun.prism.es2.ES2RTTexture.create(ES2RTTexture.java:220) at javafx.graphics/com.sun.prism.es2.ES2ResourceFactory.createRTTexture(ES2ResourceFactory.java:165) at javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:124) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) spammed alternatively.
Unable to allocate direct buffer memory
After hours of running my JavaFX application I start getting this error spammed in console: java.lang.OutOfMemoryError: Cannot reserve 149024316 bytes of direct buffer memory (allocated: 149066725, limit: 209715200) at java.base/java.nio.Bits.reserveMemory(Bits.java:178) at java.base/java.nio.DirectByteBuffer.(DirectByteBuffer.java:120) at java.base/java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:329) at javafx.graphics/com.sun.prism.impl.BufferUtil.newByteBuffer(BufferUtil.java:90) at javafx.graphics/com.sun.prism.impl.BufferUtil.newIntBuffer(BufferUtil.java:121) at javafx.graphics/com.sun.prism.impl.QueuedPixelSource.getUnusedPixels(QueuedPixelSource.java:155) at javafx.graphics/com.sun.javafx.tk.quantum.UploadingPainter.run(UploadingPainter.java:156) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125) at java.base/java.lang.Thread.run(Thread.java:832) Ironically every single error is about allocating the exact same amount of bytes.
JavaFX Memory leak
Hi,
I'm trying to debug a memory leak in my application using Java Mission
Control & Flight Recorder[1]. Going down the tree it gives, it seems to
be caused by this code:
Series series = super.getSeries();
ObservableList> points = series.getData();
if(points.size() > super.getSeconds().get()-1)
{
points.remove(super.getSeconds().get()-1);
points.add(0, new Data(0, readable.getValue().get().longValue()));
}
else
points.add(0, new Data(0, readable.getValue().get().longValue()));
for(int i = 1; i < points.size(); i++)
{
Data data = points.get(i);
data.setXValue(i+1);
}
...but doing a print statement to print the size of the Points list
shows that the max size is always 60, as expected.
This increase in memory is consistent with multiple recordings, so I do
think it's a leak but I have no idea what's causing it. Is this leak
from JavaFX's end or my code?
[1] https://imgur.com/a/oNYb6Q7
Re: Remove JavaFX JPMS enforcement
On 4/20/20 11:36 AM, Ty Young wrote: On 4/20/20 10:47 AM, Mark Raynsford wrote: Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the module path), using plain Maven builds with no special arguments, and IDEA as the IDE. This is on JDK 13, with the 13.0.2 JavaFX release from Central. From the second warning on this page: https://openjfx.io/openjfx-docs/ That's the absurd part. JavaFX 14 now requires this as a JVM runtime argument: --module-path /path/to/javafx-sdk-12/lib --add-modules javafx.controls,javafx.fxml Which wasn't required before. Not only is this a PITA and confusing but it also prevents Maven from just handling everything. Netbeans uses a custom file for runtime arguments, which the above is added to. Also, it gives JavaFX 12 as an example, which is wrong. It should be 14.
Re: Remove JavaFX JPMS enforcement
On 4/20/20 10:47 AM, Mark Raynsford wrote: Am I missing something here? What absurd arguments are required for Maven projects? I have multiple applications here running in full module-path mode (the applications are modularized, and JavaFX is on the module path), using plain Maven builds with no special arguments, and IDEA as the IDE. This is on JDK 13, with the 13.0.2 JavaFX release from Central. From the second warning on this page: https://openjfx.io/openjfx-docs/ That's the absurd part. JavaFX 14 now requires this as a JVM runtime argument: --module-path /path/to/javafx-sdk-12/lib --add-modules javafx.controls,javafx.fxml Which wasn't required before. Not only is this a PITA and confusing but it also prevents Maven from just handling everything. Netbeans uses a custom file for runtime arguments, which the above is added to.
Re: Remove JavaFX JPMS enforcement
On 4/18/20 7:40 AM, Michael Paus wrote: Hi, I would just like to add that many of the problems you have cited would just vanish if the JPMS enforcement would be removed from the JDK. There would be no "JavaFX requiring absurd runtime module VM arguments" anymore and the IDE integration would just be straight forward. JavaFX would become just one more dependency whithout the need for any special treatment. The custom Maven runtime arguments shouldn't exist, period. They didn't exist before 14 and there was zero discussion here as to why they are suddenly required on this mailing list. It just kinda came out of no where. Also, correction, the wiki is wrong: that JVM argument is ONLY for Maven projects, not Ant. I still stand that the fault isn't JPMS but rather people not willing to add documentation or support for it. When JavaFX fails to reflect on a class file or a CSS file it could suggest that it needs to be "open"ed. I did, however, not say that JavaFX should be de-modularized. For an expert user who wants to use the JPMS nothing would change at all. I'm a bit confused here. if you don't want JPMS then you should be able to run everything on the classpath like normal. Netbeans at least doesn't force modules wtih Maven. Or is reflection disabled on classpath as of Java 9 too unless you have a module-info? Michael Am 18.04.20 um 12:58 schrieb Ty Young: On 4/18/20 5:01 AM, Michael Paus wrote: Getting started with JavaFX is made overly complicated by the fact that the use of the module system is enforced by some code in the JDK. Especially for beginners, who just want to get some small program running, this is almost always a big source of frustration. It is not very good marketing for JavaFX to make these initial steps such a pain. If you need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar sites (and also this mailing list). Almost every day you can read frustrated posts from helpless people who would just like to get some JavaFX project running but are failing because they get lost in the module system jungle. Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and poor/buggy IDE support. Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: https://openjfx.io/openjfx-docs/#IDE-NetBeans Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way.
Re: Remove JavaFX JPMS enforcement
On 4/18/20 5:01 AM, Michael Paus wrote: Getting started with JavaFX is made overly complicated by the fact that the use of the module system is enforced by some code in the JDK. Especially for beginners, who just want to get some small program running, this is almost always a big source of frustration. It is not very good marketing for JavaFX to make these initial steps such a pain. If you need some evidence for this statement, then just follow JavaFX on Stackoverflow or similar sites (and also this mailing list). Almost every day you can read frustrated posts from helpless people who would just like to get some JavaFX project running but are failing because they get lost in the module system jungle. Speaking as a long time JavaFX user(literally since Java 8), I have mostly disagree that the JPMS is hurting JavaFX. That said, I don't think the frustration is misplaced. What you say is true(Netbeans mailing list is fill of JavaFX issues) and the end user is *NOT* to be blamed here. Rather, I think what's to blame is poor documentation, JavaFX requiring absurd runtime module VM arguments, and poor/buggy IDE support. Starting with documentation, JavaFX uses reflection for things like TableView(everyone's favorite) and CSS style sheets. While this may be obvious for people who are more experienced, those who are not may be very confused when they get an onslaught of error messages regarding reflection. Better documentation on what requires reflection, why, and how to enable it would be useful. Likewise, the notice about having to include javafx.graphics to the runtime module arguments here: https://openjfx.io/openjfx-docs/#IDE-NetBeans Apply to Maven as well, but it's under Ant for some reason. I don't know what was changed in JavaFX 14 that now suddenly requires a runtime VM argument, but it's a PITA and BS. End users are going to struggle with this, and it prevents JavaFX runtime from being purely managed by Maven. No other JavaFX version requires this, so it's mind boggling that all of a sudden JavaFX needs this. Poor/buggy IDE support is really the big one here. I don't know about other IDEs but Netbeans DOES NOT provide a project template for creating a JavaFX application with setup dependencies. Netbeans, when setup with a Maven project, allows you to select an entire project(pom) rather than the individual dependencies(jar) which doesn't work. What you search for also matters: if you search for "JavaFX" you will get the wrong search results. You need to search for "openjfx" which can be confusing. Anyway, yeah, it's a PITA. There is also an issue with Ant based projects and Netbeans because JavaFX puts its src.zip in a folder that is supposed to only include the runtime library that has existed for years(literally a 1 line fix too). No one really uses Ant anymore so it's probably not a big deal now but yeah, getting JavaFX working hasn't been "include and done" when it could potentially be that way.
Re: sane default option values for Linux
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?
sane default option values for Linux
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: error in tutorial
On 12/30/19 10:55 AM, Anthony Vanelverdinghe wrote: Hi Some observations: This is the mentioned e-mail: http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022497.html Thanks for finding it. The lib folder contains a src.zip file, both in JDK 13.0.1 and in JavaFX SDK 13.0.1, so this is consistent. Consistent but irrelevant. The only jar in jdk/lib is jrt-fs by default. Everything else is binary .so and properties files basically. JavaFX on the other hand has about a dozen jars and you're supposed to include all the Jars at once and/or make them a "library"(same thing, in effect). For NetBeans and IntelliJ IDEA (I didn't check Eclipse): - neither supports jmod files in libraries (see [1]) Yep. Build system and IDE support is still lacking despite Java 9 being released like 2 years ago now. - both support selecting individual jar files, after which things work as expected - neither constructs an optimal modulepath, even if the application is modular So I believe that this is mostly just a documentation issue: rather than saying "add the lib folder of the SDK" it should say "add all jar files in the lib folder of the SDK". JavaFX isn't intended to be used piecemeal. Besides, if you individually just include the jar files then the native libraries bundles with JavaFX won't be included. Additionally, IDEs should be improved to support jmod files in libraries, and to construct optimal modulepaths for modular applications. Good luck doing that. Netbeans still spits out a pre java 9 command line string that is *supposed* to be able to launch the application from the command line. It doesn't. Kind regards, Anthony [1] https://youtrack.jetbrains.com/issue/IDEA-171448 On 28/12/2019 20:11, Ty Young wrote: On 12/28/19 4:53 AM, Johan Vos wrote: Hi Ty, Since I have absolutely no idea what you are talking about, I have a few questions: 1. "... push changes to the repo..."? -> It would help giving a bit context instead of talking about "the repo". Since this is the openjfx-dev list, chances are high you're talking about the JavaFX repository at https://github.com/openjdk/jfx. In that case, please read the README and CONTRIBUTING files there for advice on how to propose/make changes (note that this will probably take longer than 1 minute, as we have strong quality checks in place). If you talk about a different "repo", please follow the explicit or implicit rules on that repo(sitory). For example, if you talk about https://github.com/openjfx/openjfx-docs , please create an issue and file a PR, and work with the community to get it accepted. (note that in this case, this should not be discussed on the openjfx-dev list (note the *dev*)). This is not an issue of documentation. IDEs can and do provide the ability to designate an entire folder as a location of project libraries. You can specify a directory manually via command line in which contains Java 9 modules. To continue to entertain the idea that this is an issue of documentation is simply crazy. It's an easily fixable technical error. 2. You refer to informal or formal talks you had, but it is totally unclear to me who you talked to about what. Frankly, we spent lots of time moving all code and as much as possible the documentation to github, so we can easily track discussions. (for JavaFX bugs, we use JBS, so that can be discussed there) If someone said "it’s the way we’ve always done it”" please refer to the issue where your request has been made and subsequently rejected, so I can have a look at the context, It was an email a very long time ago on this list. Too lazy to dig it up, but I'm pretty sure it was from Kevin Rushforth. Again, very long time ago at this point. 3. Can you write a few words about what the word "Community" means to you? Many people in the JavaFX Ecosystem spent tons of spare time in making the JavaFX "Community" a friendly place. I'm interested in your opinion about that word. To give a few options, does it mean A: I insult people and companies, use words like "smoking shrooms" and "stubborn" and I expect everything I think about to be fixed magically (since I suppose the volunteers have no life apart from doing what I want them to do) "community" is a funny word to describe JavaFX given it is 100% owned by Oracle and which no one(AFAIK) can contribute to without signing away their rights to their own code. If this was a feature request I'd understand this nonsense but that's not at all what this is. This is a self created, self perpetuated, and needlessly self harming *technical* error defended using the worst possible defense against very real issues(the creation of this thread is proof). Source files(or zips containing such) are not libraries(AKA "libs") a
Re: error in tutorial
On 12/28/19 4:53 AM, Johan Vos wrote: Hi Ty, Since I have absolutely no idea what you are talking about, I have a few questions: 1. "... push changes to the repo..."? -> It would help giving a bit context instead of talking about "the repo". Since this is the openjfx-dev list, chances are high you're talking about the JavaFX repository at https://github.com/openjdk/jfx. In that case, please read the README and CONTRIBUTING files there for advice on how to propose/make changes (note that this will probably take longer than 1 minute, as we have strong quality checks in place). If you talk about a different "repo", please follow the explicit or implicit rules on that repo(sitory). For example, if you talk about https://github.com/openjfx/openjfx-docs , please create an issue and file a PR, and work with the community to get it accepted. (note that in this case, this should not be discussed on the openjfx-dev list (note the *dev*)). This is not an issue of documentation. IDEs can and do provide the ability to designate an entire folder as a location of project libraries. You can specify a directory manually via command line in which contains Java 9 modules. To continue to entertain the idea that this is an issue of documentation is simply crazy. It's an easily fixable technical error. 2. You refer to informal or formal talks you had, but it is totally unclear to me who you talked to about what. Frankly, we spent lots of time moving all code and as much as possible the documentation to github, so we can easily track discussions. (for JavaFX bugs, we use JBS, so that can be discussed there) If someone said "it’s the way we’ve always done it”" please refer to the issue where your request has been made and subsequently rejected, so I can have a look at the context, It was an email a very long time ago on this list. Too lazy to dig it up, but I'm pretty sure it was from Kevin Rushforth. Again, very long time ago at this point. 3. Can you write a few words about what the word "Community" means to you? Many people in the JavaFX Ecosystem spent tons of spare time in making the JavaFX "Community" a friendly place. I'm interested in your opinion about that word. To give a few options, does it mean A: I insult people and companies, use words like "smoking shrooms" and "stubborn" and I expect everything I think about to be fixed magically (since I suppose the volunteers have no life apart from doing what I want them to do) "community" is a funny word to describe JavaFX given it is 100% owned by Oracle and which no one(AFAIK) can contribute to without signing away their rights to their own code. If this was a feature request I'd understand this nonsense but that's not at all what this is. This is a self created, self perpetuated, and needlessly self harming *technical* error defended using the worst possible defense against very real issues(the creation of this thread is proof). Source files(or zips containing such) are not libraries(AKA "libs") and it causes IDE issues(among other things). The fix is *really* simple. and the whole (in essence) "everyone who works on JavaFX is a someone doing it in their free time is BS. Oracle developers are payed to work on JavaFX and are the ones who originally made JavaFX(AFAIK) and (presumably) the Gradle script. If someone with basically no knowledge of Gradle such as myself can scan through a file or use ctrl + f and read variable names then I'd hope someone with actual experience could do better. Maybe I'm wrong and am the one in actuality that is smoking shrooms. B: I friendly discuss issues and opportunities with fellow community members, where I respect other opinions, keep discussions polite and technical. That's funny because I seem to remember during a JDK(or maybe it was exclusively JavaFX?) event that a presenter made a rather rude joke about my multi-threading issue I brought up on this list a long time ago. I don't remember specifically who made the joke but I do know as someone who watches said events on YouTube that those events are very incestuous. I guess because it was the other way around that it was OK though. TL;DR: People in glass houses shouldn't throw stones. C: somewhere between A and B? - Johan On Sat, Dec 28, 2019 at 12:11 AM Ty Young <mailto:youngty1...@gmail.com>> wrote: On 12/27/19 4:40 PM, John-Val Rose wrote: > Ty, > > If it’s so easy to fix then why don’t you just fix it? I don't exactly have the ability to directly push changes to the repo... > > John-Val > >> On 28 Dec 2019, at 09:14, Ty Young mailto:youngty1...@gmail.com>> wrote: >> >> >>> On 12/27/19 4:19 AM, Johan Vos wrote: >>> Hi David, >>
Re: error in tutorial
3. "community" is a funny word to describe JavaFX given it is 100% owned by Oracle and which no one can contribute to without signing away their rights to their own code. On 12/28/19 4:53 AM, Johan Vos wrote: Hi Ty, Since I have absolutely no idea what you are talking about, I have a few questions: 1. "... push changes to the repo..."? -> It would help giving a bit context instead of talking about "the repo". Since this is the openjfx-dev list, chances are high you're talking about the JavaFX repository at https://github.com/openjdk/jfx. In that case, please read the README and CONTRIBUTING files there for advice on how to propose/make changes (note that this will probably take longer than 1 minute, as we have strong quality checks in place). If you talk about a different "repo", please follow the explicit or implicit rules on that repo(sitory). For example, if you talk about https://github.com/openjfx/openjfx-docs , please create an issue and file a PR, and work with the community to get it accepted. (note that in this case, this should not be discussed on the openjfx-dev list (note the *dev*)). This is not an issue of documentation. IDEs can and do provide the ability to designate an entire folder as a location of project libraries. You can specify a directory manually via command line in which contains Java 9 modules. To continue to entertain the idea that this is an issue of documentation is simply crazy. It's an easily fixable technical error. 2. You refer to informal or formal talks you had, but it is totally unclear to me who you talked to about what. Frankly, we spent lots of time moving all code and as much as possible the documentation to github, so we can easily track discussions. (for JavaFX bugs, we use JBS, so that can be discussed there) If someone said "it’s the way we’ve always done it”" please refer to the issue where your request has been made and subsequently rejected, so I can have a look at the context, It was an email a very long time ago on this list. Too lazy to dig it up, but I'm pretty sure it was from Kevin Rushforth. Again, very long time ago at this point. 3. Can you write a few words about what the word "Community" means to you? Many people in the JavaFX Ecosystem spent tons of spare time in making the JavaFX "Community" a friendly place. I'm interested in your opinion about that word. To give a few options, does it mean A: I insult people and companies, use words like "smoking shrooms" and "stubborn" and I expect everything I think about to be fixed magically (since I suppose the volunteers have no life apart from doing what I want them to do) "community" is a funny word to describe JavaFX given it is 100% owned by Oracle and which no one(AFAIK) can contribute to without signing away their rights to their own code. If this was a feature request I'd understand this nonsense but that's not at all what this is. This is a self created, self perpetuated, and needlessly self harming *technical* error defended using the worst possible defense against very real issues(the creation of this thread is proof). Source files(or zips containing such) are not libraries(AKA "libs") and it causes IDE issues(among other things). The fix is *really* simple. and the whole (in essence) "everyone who works on JavaFX is a someone doing it in their free time is BS. Oracle developers are payed to work on JavaFX and are the ones who originally made JavaFX(AFAIK) and (presumably) the Gradle script. If someone with basically no knowledge of Gradle such as myself can scan through a file or use ctrl + f and read variable names then I'd hope someone with actual experience could do better. Maybe I'm wrong and am the one in actuality that is smoking shrooms. B: I friendly discuss issues and opportunities with fellow community members, where I respect other opinions, keep discussions polite and technical. That's funny because I seem to remember during a JDK(or maybe it was exclusively JavaFX?) event that a presenter made a rather rude joke about my multi-threading issue I brought up on this list a long time ago. I don't remember specifically who made the joke but I do know as someone who watches said events on YouTube that those events are very incestuous. I guess because it was the other way around that it was OK though. TL;DR: People in glass houses shouldn't throw stones. C: somewhere between A and B? - Johan On Sat, Dec 28, 2019 at 12:11 AM Ty Young <mailto:youngty1...@gmail.com>> wrote: On 12/27/19 4:40 PM, John-Val Rose wrote: > Ty, > > If it’s so easy to fix then why don’t you just fix it? I don't exactly have the ability to directly push changes to the repo... > > John-Val > >> On 28 Dec 2019, at 09:
Re: error in tutorial
On 12/27/19 4:40 PM, John-Val Rose wrote:
Ty,
If it’s so easy to fix then why don’t you just fix it?
I don't exactly have the ability to directly push changes to the repo...
John-Val
On 28 Dec 2019, at 09:14, Ty Young wrote:
On 12/27/19 4:19 AM, Johan Vos wrote:
Hi David,
What tutorial are you talking about? If you refer to https://openjfx.io,
that is a community-initiative, developed at
https://github.com/openjfx/openjfx-docs .
So if you have issues and PR's, that is the place to submit and discuss
with the other contributors to that site.
Only the Netbeans section has a warning telling you to delete src.zip. Neither
Intellij nor Eclipse do.
A user shouldn't have to do that anyway though! This could be easily fixed.
Literally all you need to do is in this section:
// Zip module sources for standalone SDK
//
// NOTE: the input is taken from the modular-sdk/modules_src dir
// so that we don't have to duplicate the logic and create another
// temporary directory. This is somewhat inelegant, since the bundled sdk
// and the standalone sdk should be independent of one another, but seems
// better than the alternatives.
def zipSourceFilesTask =
project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn:
buildModulesTask) {
destinationDir = file("${standaloneLibDir}")
archiveName = standaloneSrcZipName
includeEmptyDirs = false
from modulesSrcDir
include "**/*.java"
}
change:
Re: error in tutorial
On 12/27/19 4:19 AM, Johan Vos wrote:
Hi David,
What tutorial are you talking about? If you refer to https://openjfx.io,
that is a community-initiative, developed at
https://github.com/openjfx/openjfx-docs .
So if you have issues and PR's, that is the place to submit and discuss
with the other contributors to that site.
Only the Netbeans section has a warning telling you to delete src.zip.
Neither Intellij nor Eclipse do.
A user shouldn't have to do that anyway though! This could be easily
fixed. Literally all you need to do is in this section:
// Zip module sources for standalone SDK
//
// NOTE: the input is taken from the modular-sdk/modules_src dir
// so that we don't have to duplicate the logic and create another
// temporary directory. This is somewhat inelegant, since the
bundled sdk
// and the standalone sdk should be independent of one another, but
seems
// better than the alternatives.
def zipSourceFilesTask =
project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn:
buildModulesTask) {
destinationDir = file("${standaloneLibDir}")
archiveName = standaloneSrcZipName
includeEmptyDirs = false
from modulesSrcDir
include "**/*.java"
}
change:
destinationDir = file("${standaloneLibDir}")
to:
destinationDir = file("${standaloneSdkDir}")
That's it. Literally less than a minute, like I said. You can put zip
files in zip files, it doesn't matter. This is a really stupid thing to
be stubborn about.
Thanks,
- Johan
On Thu, Dec 26, 2019 at 9:26 PM David Green
wrote:
This step fails:
3\. Create a library
Go to File - Project Structure - Libraries and add the JavaFX 13
SDK
as a library to the project. Point to the lib folder of the JavaFX SDK.
The src.zip located in this package lib will cause the build in IJ to
fail. I
don't know why, since it is source, albeit zipped.
To get the project to build, I had to remove it. I placed it in a new src
folder I created at the same level as lib in the sdk.
Re: Previews for shared buffer PR
On 6/7/19 4:40 AM, Johan Vos wrote: The PR discussed in https://github.com/javafxports/openjdk-jfx/pull/472, addressing https://bugs.openjdk.java.net/browse/JDK-8167148 provides a very much wanted feature. It is important that things are done in the right way so that the code can be maintained in the long-term future. Therefore, feedback on this PR is extremely important before we can consider merging it. Once this PR is merged, there is no easy way back. It is possible to add more functionality, hence my preference is to only implement the functionality that is safe and stable, while allowing other functionality to be added later or by third-party extensions. (e.g. (avoiding) copying from/to GPU) To make it easier to give feedback, we've build early access versions of SDK's including this PR. Note that the PR is not merged, hence not available in the regular EA downloads! If you want to give it a try, download the SDK's from the URL's below. There is a test in tests/manual/graphics/PixelBufferPerformanceTest ( https://github.com/arapte/openjdk-jfx/blob/JDK-8167148-NIO-ByteBuffer/tests/manual/graphics/PixelBufferPerformanceTest.java) that should get you started. https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-jmods.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_linux-x64_bin-sdk.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-jmods.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_osx-x64_bin-sdk.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-jmods.zip https://download2.gluonhq.com/openjfx/forks/pixelbuffer/openjfx-13-pixelbuffer-ea+9_windows-x64_bin-sdk.zip - Johan FYI this SDK causes a hard system crash when GTK is set to 2 and/or prism.forceUploadingPainter is set to true. I don't feel like purposefully crashing my system to see which of the various combinations is the issue so forgive me for not providing a more narrowed down cause. GTK 2 is still necessary as there are still lingering GTK3 bugs that have yet to be fixed even in current JavaFX 13. prism.forceUploadingPainter is a prism setting that fixes buffer resets and other various GUI glitching under Linux(an issue I tried reporting a long time ago) which affects ALL JavaFX applications under Linux but dramatically increases GPU utilization by 2x-2.5x when doing any kind of application interaction(resizing, scrolling, etc). Is there a reason this isn't enabled by default under Linux besides performance? Where is the documentation for this and other settings? I randomly ran into this from http://werner.yellowcouch.org/log/javafx-8-command-line-options/ and was surprised noone really knows about it nor is it documented anywhere that I can see. Even with GTK 3 this results in a null pointer exception: java.lang.NullPointerException at javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:223) at javafx.graphics/com.sun.prism.es2.ES2SwapChain.createGraphics(ES2SwapChain.java:40) at javafx.graphics/com.sun.javafx.tk.quantum.PresentingPainter.run(PresentingPainter.java:87) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) at javafx.graphics/com.sun.javafx.tk.RenderJob.run(RenderJob.java:58) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(QuantumRenderer.java:125 Please don't merge this into JDK13 or at least provide a switch to disable it. This is extremely busted on Linux. Can the source code for this entire JavaFX build please be linked?
BUG: TreeView setPrefHeight CSS freakout
Attempting to set the preferred height of a TreeView or content that would otherwise expand the component(super.setPrefHeight or another component in the containing node) results in a massive freakout resulting in a memory leak and extremely high CPU usage. Using Netbean's method profiler[1] shows that VirtualFlow.addTrailingCells is taking 130 seconds. Going down a leaf shows that Node.applyCss and Node.processCss are taking up the majority(all? Numbers aren't adding up.) of the time and presumably causing the memory leak and high CPU usage. Even after removing any custom CSS stylesheets this still happens. This only seems to affect TreeView as well as no other component(maybe ListView since they are similar?) has this issue. Maybe related is a CSS bug where an in-between state between a scrollbar showing in the TreeView and when there is not. In this state, a visible white space can be seen at the bottom where the scrollbar was(although the white space is smaller). If you are using the default JavaFX CSS stylesheet you won't see this as the background color is white. Clicking a TreeView item seems to update the TreeView and fix this white space issue. ScrollPane and ScrollBars are really broken in JavaFX in general under Linux so its hard to say whether or not it is related. Any ideas on what's causing all this? [1] https://imgur.com/a/DT3eiNj
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
On 1/17/19 12:55 PM, Siddhesh Rane wrote:
January 16, 2019 11:31 PM, "Ty Young" wrote:
How else is percentage based UI sizing besides DoubleBinding(s)? Isn't column
restraints just the
same thing but aligns everything to a column?
I have to ask(again) as to why minWidth/maxWidth, minHeight/maxHeight,
prefWidth/prefHeight aren't
read only if this is going to be an *always* realistically going to be an issue.
Column constraints don't use any bindings, neither do any other layout panes.
{min,pref,max} width/height are merely hints for a parent to layout the child.
They are not the final authority on child size. The actual final size of a
child is set by calling Node#resize on it, which is what the parent does during
the Parent#layoutChildren call. During this call the parent knows about its own
size and can split that space among the children.
A rogue parent could completely ignore these hints and resize the child to
whatever it wants.
The documentation on the sizing says that they override the computed size.
On your second point, it is only an issue if you use it in the wrong way,
without understanding.
Excuse me? There is no documentation AFAIK stating that this would ever
be an issue nor would anyone look at the UI and think that a GridPane is
necessary to achieve such a basic layout. The use of GridPane seems more
like a hacky workaround for something JavaFX seemingly has no other way
to achieve with more appropriate layout management nodes(VBox, HBox,
etc) without side affects.
I wanted to place the buttons and Scrollpane in a horizontal fashion, so
I used an HBox. I wanted to dynamically size the nodes based on a
percentage of the window's total width/height, so I used property
bindings to force content to the desired correct. If that causes issues
then maybe all controls should get a supported percentage based way to
set the width/height like GridPane's columns with appropriate layout
nodes so people don't try doing this sort of thing.
You bound the minWidth of a scrollpane's content to 85% of the scrollpane's
widthProperty (which is actual width).
When you resize the scrollpane to <85% of its original size, its content still
has the old minWidth property which is greater than the current width of the
scroll pane. So the scrollpane shows horizontal bar. This is not a bug.
widthProperty is supposed to be valid after layout.
This explains the ScrollPane horizontal scrollbar glitching out but
doesn't explain TableView's horizontal scrollbar.
Use bindings for size if you want to do some advanced sizing. Like size
matching unrelated nodes with different parents to get some visual effect. You
could create a custom textarea that binds minWidth to the number of characters
in the first line.
I have never had a use case but someone else might.
Use it for cases where there is no mutual dependency or "race condition".
I saw your code and I can confirm this is the main cause.
If you want a 15-85 % split, you should have used a GridPane with two columns
with the given
percentage constraints.
This works for the buttons/scrollpane but what about the subcontent?
TableView's scrollbars also
glitch out in the exact same way.
Set scrollpane to fit to width. Add a gridpane with a single column whose
column width is set to 85%. Set gridpane alignment to center. Drop the bindings
and your problems will be solved.
It isn't completely solved but it is better I guess. ScrollPane's
horizontal bar no longer glitches out and resizing performance has
increased majorly. TableView still glitches out from time to time and
app content is still jumping all over the place. Bindings are still
needed for the size of the main GridPane and other misc nodes. It seems
to be a bug caused by indirect resizing of the table itself...
And the vertical scrollpane bar is missing from the Overview content.
Setting the show policy to Always shows it being there where it should
be and is usable(regardless of policy) via scroll wheel. No other
section has this issue.
Font rendering is also still an issue...
SceneBuilder's lack of UI snapping compared to Netbean's Swing builder makes it
incredibly
difficult to get anything remotely pixel perfect without banging your head
against a wall. Separate
controller classes and FXML annotations everywhere isn't really desirable
either. I originally
entertained the idea of doing it all in FXML only to quickly discard the idea.
If you are talking about snapping like in aligning to other UI elements, then
its there and you dont need it with the rought layout. If you mean snapping to
pixels, JavaFX has it inbuilt and on by default.
It is but it is incomplete. Try resizing a Button in both SceneBuilder
and Netbean's Swing builder to the bottom right after first snapping to
the top left. The button will snap perfectly to both in the Swing
builder but not SceneBuilder.
Regards
Siddhesh
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
On 1/13/19 5:33 PM, John Neffenger wrote: On 1/12/19 10:20 PM, Ty Young wrote: Seeing as how this important issue is seemingly being ignored, I've decided to upload a video showcases the bugs[1]. If this isn't evidence that there is a problem with JavaFX's content rendering, resizing, and fonts I don't know what is. Your video looks similar to a bug I first encountered two years ago [1]. I was reluctant to reply earlier because I can't reproduce the bug in a windowed environment. So far I have seen the problem in the two cases listed below (the bug report lists only the first case): (a) on a Monocle platform using an off-screen composition buffer that is allocated as a non-direct byte buffer, and (b) on a Monocle platform using the frame buffer directly as the composition buffer, and its horizontal visible resolution differs from its virtual resolution. If I play your videos at the slowest speed, I see the entire frame jump up when you resize its window. That is just what you would expect if the position of the buffer was reset to zero while the buffer was being used to draw the frame. ...and can cause undefined behavior like horizontal scrollbars showing when they shouldn't I assume? Does JavaFX only have one frame buffer? If so, would it not be possible (and safer) to have a primary buffer and a secondary "prefetch" frame buffer to safely create the next frame buffer to ensure that this doesn't happen? So that: 1. UI update happens(resize, control clicked, etc) 2. "prefetch" buffer immediately draws the next frame and keeps drawing frames if UI updates keep happening 3. primary buffer is replaced with the newest complete "prefetch" buffer In otherwords, similar to double and triple buffering. Of course, just like with double/triple buffering this can cause side affects. Our environments are very different, and your problem may have origins outside of JavaFX entirely, but it may still be worth trying the same debugging technique described in the bug report. The waving Duke project no longer works in JavaFX 11. Is there an easy way to do similar in any JavaFX project using the latest JavaFX? I created a new JavaFX/JDK build with the submitted commit and it doesn't improve anything. It could just be placebo but it may have actually made it worse. John [1] See: https://bugs.openjdk.java.net/browse/JDK-8201567 or: https://gitlab.com/openjfxepd/jfxpatch/issues/1
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
Seeing as how this important issue is seemingly being ignored, I've decided to upload a video showcases the bugs[1]. If this isn't evidence that there is a problem with JavaFX's content rendering, resizing, and fonts I don't know what is. The issues I'm experiencing affect every single JavaFX application that I've tested, which is: Goliath Envious FX(mine, repo linked earlier) Scenic View Scene Builder PlayOnLinux 5 Of special note is Scenic View. For reasons I don't understand, Scenic View does not always show the glitching. It, however, has extremely laggy resizing. Even when it isn't glitching however, it is always possible to make it happen by going to Help > About and closing the About window that pops up. Node count for my app is 422 at most and about 150 at its lowest. This number will increase/decrease with the amount of Nvidia GPUs connected to the system. That decreases or increases depending on the content being shown. I have no idea where or how it is even that high seeing as how hardly anything is even on the screen to begin with. Font boldness bug can be found at 6-8 second range in the video. It used to happen in a different part of the GUI... Can we please actually talk about what the actual issues are instead of blaming the end programmers and/or excuses like "it's just too complex"? Please? Side note 1: to whoever is developing Scenic View(assuming they are subscribed to this list), your application spits out errors like crazy(see the video). java.instrument was exported in module-info yet it threw errors saying otherwise. Application output was throwing connection refused exceptions left and right. Some X related code was spitting out a colored error message saying java was doing something networking(?) related that it shouldn't and "please stop that" or other. I didn't copy the exact text sadly. Also, specify a min width/height. Side note 2: I was wrong about JavaFX not supporting 1440p and 4k. It uses GDK_SCALE to scale the UI. Problem is, GDK_SCALE isn't a reliable way of getting the actual UI scale and will only work for native displays at native resolutions. Using xrandr to scale the output display results in 1x scaling even though the DE is being rendered in 4k. I'm guessing this is related to having to log back out and log back in in Windows. It would be nice if JavaFX had failsafe code to dynamically handle this. [1] https://youtu.be/Jin9pQBhDnQ
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
On 1/9/19 2:38 AM, Ty Young wrote: On 1/9/19 1:59 AM, Tom Schindl wrote: On 09.01.19 06:13, Ty Young wrote: I've done a fresh build of JavaFX 12 and JDK 13(12 hasn't been released yet but apparently 13 is a thing). These issues still exist. To really help finding and solving the problem you need to provide source code for us to reproduce the problem. Tom For the actual application see the repo[1]. I've uploaded a new release(see releases page) which can be used to actually run without compiling. Requirements to run are of course Linux but also: 1. A modern Nvidia GPU 2. Nvidia GPU driver(newer is better) 3. Nvidia-smi(should come with driver) 4. Nvidia-settings(may ship with binary driver depending on distro). If a dummy GUI is necessary I can strip anything that isn't JavaFX. MainAppContentBox.java and the content of the various "NavButton"(s) is the most relevant bits. [1] https://github.com/BlueGoliath/GoliathEnviousFX
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
I've done a fresh build of JavaFX 12 and JDK 13(12 hasn't been released
yet but apparently 13 is a thing). These issues still exist.
Unrelated to JavaFX but client builds of the JDK fail with config
--disable-warnings-as-errors --with-jvm-variants=client
--with-import-modules=../rt/build/modular-sdk. What list should this be
reported to?
On 1/2/19 6:27 PM, Ty Young wrote:
(I'm too lazy to make different emails for every bug so I've just
thrown them in a single email. Hopefully that isn't a big deal.)
In my attempt to write a more proper responsive JavaFX UI, I've
created a new JavaFX project which extensively uses DoubleBindings to
force the min/max width/height of various components to their parent
containing objects(HBox and VBox mainly) so that 1440p and 4k displays
could be more easily supported. While it does allow for easier 1440p
and 4k scaling, JavaFX itself seems to have /extremely/ horrible
content rendering & resizing bugs to the point where the application
becomes usable.
For clarity, the applications uses buttons in a VBox which when
clicked set a ScrollPane on the right side to whatever pane the button
represents("About" for example) like a TabPane. This is so it can be
scaled more easily to different resolutions.
Multiple of the bugs can be observed by simply resizing the JavaFX
window. When doing so, content will seemingly struggle to keep up with
resizing events. As a result, white(or sometimes black) glitching can
be seen wherever the window is being expanded and UI components will
"jump" around. TableView's horizontal and vertical scrollbars will
glitch out and show while the window is being resized even though it
has plenty of room to display the contents. They sometimes even get
stuck, requiring the user to resize the window for them to go away.
If the window is resized or if the window is maximized and later
unmaximized , any non visible content will not be resized and will
require that the window be resized by the user. A horizontal scroll
bar will be displayed and usable to scroll to the content that hasn't
been adjusted to the new window size. Sometimes JavaFX will slowly
resize the content in seemingly steps however it doesn't always do this.
Thinking that this might be problems caused by extensive use of
DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
has all of the same UI glitching that I've encountered in my JavaFX
application at a lesser scale besides TableView since it doesn't use
TableView.
The degree of how badly the bugs happen seemingly depend on:
A. The app launch
B. The time the application is open
C. The max stretched width/height of the window
In other words, it's possible to experience little UI glitching one
app launch while using it after awhile but then relaunch it later with
no code changed and get far more glitching.
Another problem is a font bug revolving around making text bold. When
attempting to make a label bold, the boldness is seemingly not being
applied to some Label text. It might work on a few Labels in a certain
part of the UI but completely refuse in other parts. Making things
weirder is the disappearing boldness of Labels after setting a new
Pane in the ScrollPane and switching back to a that specific pane.
For example: on first click to the pane two labels will be bold as set
in code. Switching to another pane and back results in the last bold
label not being bold anymore. Switching to another pane again results
in the first Label no longer being bold.
All of these bugs make the application unusable(except the boldness
bug). Is this all known? Are there any workarounds?
P.S. To whoever is developing SceneBuilder, please add a minimum
width/height to the stage. A user shouldn't be able to make resize the
window to 1x5 or whatever the smallest window size is allowed by the OS.
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
On 1/6/19 5:06 AM, Siddhesh Rane wrote: (An earlier version of this email turned out completely empty when delivered on the mailing list) I have used JavaFX on Linux since 8.0 and have never faced any serious issues. January 3, 2019 4:29 AM, "Ty Young" wrote: In my attempt to write a more proper responsive JavaFX UI, I've created a new JavaFX project which extensively uses DoubleBindings to force the min/max width/height of various components to their parent containing objects(HBox and VBox mainly) so that 1440p and 4k displays could be more easily supported. This is not how layout is supposed to be done. The parent container calculates its computed size based on its children which takes into account min/pref/max size of children. Min/pref/max are intrinsic properties of the child irrespective of the container it is in. You are introducing a chicken and egg situation here by having both dimensions depend on each other. You'll get undefined behaviour. If you want children to occupy full width and height of parent, set VBox to "fill width" with Vgrow ALWAYS on children and Hbox to "fill height" and hgrow always in scene builder. I'm well aware of how the parents size is calculated. However, the more level top level UI components are percentage based of the entire window so that, for example, the left button is 15% of the total window width and the ScrollPane is 85% of the total window width. Content within the ScrollPane is also reduced to 85% of the ScrollPane's width. This percentage based UI scaling has been done in website for years. There isn't anything particularly different here. Content should theoretically be resized in a top down fashion on any resize event after first creation. If this causes unnecessary resizing events then why exactly does the DoubleBinding API even exist to begin with? This is always going to be an issue when you use it. While it does allow for easier 1440p and 4k scaling, JavaFX itself seems to have /extremely/ horrible content rendering & resizing bugs to the point where the application becomes usable. If you are taking about buttons being extremely small on high definition screens on Linux, you can set root font size in your css to >1.0em. Alternatively you can set default font size with - Dcom.sun.javafx.fontSize=18 where default is 12. You can try it for any javafx application by setting _JAVA_OPTIONS=-Dcom.sun.javafx.fontSize=18 on the command line. As far as I'm aware JavaFX uses the system default font size unless told otherwise. As such, font should scale perfectly on native displays. Problem is, this is not true when using xrandr to scale the viewport nor does it affect padding or spacing between UI elements so while it'll supposedly look fine using a more responsive application design like i've been doing it will be less 1:1 scaling. Extra handling is required for above 1080p scaling sadly. Default font size is 13 according to Font.getDefault().getSize(). According to Gnome Tweaks it's supposed to be 11. Which one is right? Who knows. Maybe using Font.getDefault().getSize() isn't a reliable way of getting system font size but I can't immediately think of a better way to get the actual system font size. Multiple of the bugs can be observed by simply resizing the JavaFX window. When doing so, content will seemingly struggle to keep up with resizing events. As a result, white(or sometimes black) glitching can be seen wherever the window is being expanded and UI components will "jump" around. White or black bars on window expansion are not specific to javafx. I've seen that on Windows file explorer and Chrome with Gmail tab. It seems to me that the window resizing happens asynchronously so it doesn't wait for the application to have calculated layout and painted the new area. For any complex UI, the layout computation cannot keep up with window resize. In complete honestly I've never really payed much attention to window resizing behavior until now as I usually just keep applications maximized. Opening various applications and resizing them shows that while there are far more applications with glitchy and low FPS resizing, there are also examples of applications that have no trouble resizing UI components. Non glitchy: Gnome Settings(My app design is roughly based on this. It too uses percentage based UI sizing without issue.) Gnome Disks QT5 Settings GNU Octage Only Office Vid Cutter Glitchy: JavaFX apps Netbeans WPS Office Steam(game client) Given that some applications with fairly complex UI work fine I don't really buy the "UI is just too complex!" theory/defense/excuse. Not only does the app use bog standard JavaFX UI components but there aren't that many on the screen at any given time. Going by behavior of ScrollPane's glitchy horizontal bar, JavaFX doesn't even resize UI content that isn't in a use
Re: JavaFX Content Rendering & Resizing and Font Bugs In Linux
On 1/2/19 6:27 PM, Ty Young wrote:
(I'm too lazy to make different emails for every bug so I've just
thrown them in a single email. Hopefully that isn't a big deal.)
In my attempt to write a more proper responsive JavaFX UI, I've
created a new JavaFX project which extensively uses DoubleBindings to
force the min/max width/height of various components to their parent
containing objects(HBox and VBox mainly) so that 1440p and 4k displays
could be more easily supported. While it does allow for easier 1440p
and 4k scaling, JavaFX itself seems to have /extremely/ horrible
content rendering & resizing bugs to the point where the application
becomes usable.
For clarity, the applications uses buttons in a VBox which when
clicked set a ScrollPane on the right side to whatever pane the button
represents("About" for example) like a TabPane. This is so it can be
scaled more easily to different resolutions.
Multiple of the bugs can be observed by simply resizing the JavaFX
window. When doing so, content will seemingly struggle to keep up with
resizing events. As a result, white(or sometimes black) glitching can
be seen wherever the window is being expanded and UI components will
"jump" around. TableView's horizontal and vertical scrollbars will
glitch out and show while the window is being resized even though it
has plenty of room to display the contents. They sometimes even get
stuck, requiring the user to resize the window for them to go away.
If the window is resized or if the window is maximized and later
unmaximized , any non visible content will not be resized and will
require that the window be resized by the user. A horizontal scroll
bar will be displayed and usable to scroll to the content that hasn't
been adjusted to the new window size. Sometimes JavaFX will slowly
resize the content in seemingly steps however it doesn't always do this.
Thinking that this might be problems caused by extensive use of
DoubleBinding, I launched SceneBuilder 10 which uses Oracle JDK 10. It
has all of the same UI glitching that I've encountered in my JavaFX
application at a lesser scale besides TableView since it doesn't use
TableView.
The degree of how badly the bugs happen seemingly depend on:
A. The app launch
B. The time the application is open
C. The max stretched width/height of the window
In other words, it's possible to experience little UI glitching one
app launch while using it after awhile but then relaunch it later with
no code changed and get far more glitching.
Another problem is a font bug revolving around making text bold. When
attempting to make a label bold, the boldness is seemingly not being
applied to some Label text. It might work on a few Labels in a certain
part of the UI but completely refuse in other parts. Making things
weirder is the disappearing boldness of Labels after setting a new
Pane in the ScrollPane and switching back to a that specific pane.
For example: on first click to the pane two labels will be bold as set
in code. Switching to another pane and back results in the last bold
label not being bold anymore. Switching to another pane again results
in the first Label no longer being bold.
All of these bugs make the application unusable(except the boldness
bug). Is this all known? Are there any workarounds?
P.S. To whoever is developing SceneBuilder, please add a minimum
width/height to the stage. A user shouldn't be able to make resize the
window to 1x5 or whatever the smallest window size is allowed by the OS.
I've also just tested this in Ubuntu 18.04 as well via a jlink bundle.
All of the window resizing and content jumping bugs exist on it as well.
Does anyone know anything?
Re: JavaFX fails to build with multiple different issues
On 12/3/18 6:52 PM, Michael Ennen wrote: The first one is definitely a bug and I would consider opening a PR to remove the final modifier on https://github.com/javafxports/openjdk-jfx. Done. <https://github.com/javafxports/openjdk-jfx/pull/313> This is the first time I've ever done a PR request so if there is anything wrong besides not signing away my left kidney with my own blood then let me know(/joke). I don't think it has any negative impact seeing as how the code requires the instance to be mutable anyway unless this really is a different code path from before(why would it be?) but I can't exactly check either way until I can compile and it's wrong either way. The second one is a gradle error - what gradle command-line invocation are you using? "gradle build" though just doing "gradle" or even "gradle clean" results in the same fail. All tasks are borked would be my guess. On Mon, Dec 3, 2018 at 4:58 PM Ty Young <mailto:youngty1...@gmail.com>> wrote: So here is an odd one: JavaFX is now longer building on Arch Linux even on a previous source directory that did compile just fine. I'm guessing that something was updated and isn't compatible with JavaFX's build scripts but I'm not entirely sure what exactly it is. (Note: just to make sure the files didn't magically become corrupt or something I redownloaded from the Github mirror. Same issue.) First error is this: ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy: 118: The variable [files] is declared final but is reassigned . At [118:21] @ line 118, column 21. files += file; which is easy enough to fix by simply removing final from line 105. Even though this was clearly an issue(why use final on local variables? I've never understood why people do it...), I'm not entirely sure why it's throwing an error now. Is it because Groovy is a scripting language and the build scripts never used to follow that logic path? Next issue is this: > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer which I'm not sure on how to resolve. Thinking that it may be related to my custom built JDK I tried swapping it out for an older one that I know worked before and yet it fails all the same. -- Michael Ennen
JavaFX fails to build with multiple different issues
So here is an odd one: JavaFX is now longer building on Arch Linux even on a previous source directory that did compile just fine. I'm guessing that something was updated and isn't compatible with JavaFX's build scripts but I'm not entirely sure what exactly it is. (Note: just to make sure the files didn't magically become corrupt or something I redownloaded from the Github mirror. Same issue.) First error is this: ~/openjdk-jfx-develop/buildSrc/src/main/groovy/com/sun/javafx/gradle/NativeCompileTask.groovy: 118: The variable [files] is declared final but is reassigned . At [118:21] @ line 118, column 21. files += file; which is easy enough to fix by simply removing final from line 105. Even though this was clearly an issue(why use final on local variables? I've never understood why people do it...), I'm not entirely sure why it's throwing an error now. Is it because Groovy is a scripting language and the build scripts never used to follow that logic path? Next issue is this: > Could not get unknown property 'moduleEmptyPublicationJarLinux' for task set of type org.gradle.api.internal.tasks.DefaultTaskContainer which I'm not sure on how to resolve. Thinking that it may be related to my custom built JDK I tried swapping it out for an older one that I know worked before and yet it fails all the same.
Re: Netbeans X & Java 11?
On 11/18/18 3:01 PM, Michael Dever wrote: Oracle seems to have Destroyed the combination of: Netbeans, JavaFX, and SceneBuilder, building JavaFX from an IDE. Is there any other IDE that supports and builds: JavaFX FXML Applications, out of the box that just works, and that you can design the GUI application from SceneBuilder? Thanks, Mike Dever Hi Mike, I'm assuming you're getting a missing JavaFX deployment error which is the only error I could get with Java 11/JavaFX11 JDK in Netbeans with FXML and non modular application in Linux. As result of Oracle's careless deprecation and removal rampage, none of the non modular JavaFX applications in Netbeans(even 9!) work regardless of whether your JavaFX application is FXML or Java(which is all of templates/samples, by the by). I've brought this up before on this mailing list before in a bit of a rant and no one seemed to care to acknowledge that it was even an issue. There is some effort to make a replacement however it's being spearheaded by a company other than Oracle(abd IIRC is fit for primarily their needs. I couldn't get it to work for my jLink app) and who know when or if at all it will be integrated into JavaFX and Netbeans. You can work around this by moving to a modular application. Sadly, Netbeans 9 does not provide any easy way to convert projects to the modular structure. Fortunately the process for converting it by hand is fairly easy for simple small projects: 1. Create a new modular application in Netbeans. 2. Copy /src/ to the modular applications /src/classes/ 3. Fix module name in module-info and add exports. This will break Git(or at least it did for me). Yes, it really sucks but this is what happens when companies abort useful tools/secondary features out of the blue like an unwanted child without warning, proper & complete replacement, or time for IDE developers to add features to help migrate users of these features gracefully. This corporate middle fingering "It's our way or the highway" attitude is only going to hurt Java as a whole as no one can depend on anything for any long period of time and what tools/secondary features are being supported for the time being don't have all the features or functionality that deprecated features do. To add icing to the cake, Netbeans was formerly developed by Oracle themselves. Ouch. But now I'm just repeating myself and going off topic. Yeah, if it's a small project the above should work fine. You might even be able to automate it if you really need to. Hope this helps.
Re: Bug: Not on FX application thread exception is inconsistent
On 11/13/18 12:12 AM, Tom Schindl wrote: I'm sorry that I'm the one to bring you the bad news that you need to do the work and can't offload multi-threading to JavaFX. I already explain why it *seems* to work one some elements (until it breaks like shown in the bug-report I referenced) and for others it breaks immediately because they somehow call out to native APIs (like win32, ...) and hence are guarded with checks. I can simply say it won't work and it won't change (well I'm not the one in charge of such a decision but I frankly can't believe it will). You are the one supposed to deal with this like you have to deal with that in Swing, Qt, WPF, Win32-API, Cocoa-API, Gtk, ... - you need to sync yourself back to the UI-Thread if you want to access resources. You are right. If there are many updates from the backend-system you would queue a lot of Runnables using Platform.runLater() who can get you in trouble. There are others ways to sync back to the JavaFX UI-Thread but Platform.runLater() is the simplest with the least amount of work and until you run into problems you should stick to that. Because everything is ran in different places and there is no built-in way to wait for the runnable to finish, some GUI code that notifies the user of an API object's change breaks because the object hasn't been updated yet. This is my last reply in this thread, as there's nothing more to say on this topic from my side, there are many resources out there discussing Platform.runLater and friends but that's something you can (and could have) googled for and anyways looks like you don't want to listen. All Google turns up is Platform.runLater and Platform.runAndWait. Platform.runAndWait isn't even publicly usable unless I edit the source and make it public. I knew using Platform.runLater was going to cause problems which is why I really didn't want to use it to begin with. This isn't me not doing my research, this is objectively JavaFX not providing the functionality that is necessary to do something rather trivial: update an API object and provide information from that API object right after it's updated to the user(without ChangeListener). I understand that there may be very technical reasons for not making it public, however it is still *majorly* problematic that it doesn't exist. Not being able to tell when a runnable has finished executing(besides ChangeListeners) is a big deal. Tom On 13.11.18 05:38, Ty Young wrote: On 11/12/18 9:12 PM, Brian Hudson wrote: JavaFX like every other modern UI framework is single threaded. Which in itself is fine, running *just* the UI isn't much on modern processors. Adding a bunch of API object updates that cause thread slowdown to the mix that can cause UI stuttering is, again, asking for trouble. And how is TableView, Slider, TextField, etc all working just fine but ComboBox freaks out? What's so special about ComboBox? Is there some hack I can do to not trigger the exception? The updating of your “API objects” can and should remain on a background thread, however once updated the changes which trigger an update to your UI (changing a value in a bound property) should occur on the JavaFX thread via Platform.runLater for example. Doing all this is just messy, inefficient, and duplicating code. It would involve creating Runnable implementations that does about 10 lines of code with objects that get updated as fast as they can be with different object types, resulting in more threads and garbage being created. Using generic magic isn't really a solution either because different API objects convert data from String to some other type depending on the implementation. Would it not be possible to have a runPlatformListener method that just runs the ChangeListener on the platform thread automatically? It would reduce the amount of garbage dramatically since JavaFX only ever fires a change event if the object is itself different(in other words, if the current value is 0 and the new value is 0, there is no change) which is nice and efficient. Also, take the attitude down a notch or two. Brian On Mon, Nov 12, 2018 at 10:02 PM Ty Young mailto:youngty1...@gmail.com>> wrote: On 11/12/18 5:39 PM, Tom Schindl wrote: > Hi, > > You are supposed to interact with Nodes who are currently shown in the > SG only only the JavaFX Application Thread. I never touch the GUI in my other threads, ever. The threads simply change the value of a type stored in a property. The ChangeListener that is used is created in the GUI JavaFX thread. > > JavaFX although is not checking each and every property (change) as this > would be too resource intensive but at sensitive cases (eg when > interacting with Glass) it does check that you run on the correct thread. The update process for updating my API objects is slow(for reasons
Re: Bug: Not on FX application thread exception is inconsistent
On 11/12/18 9:12 PM, Brian Hudson wrote:
JavaFX like every other modern UI framework is single threaded.
Which in itself is fine, running *just* the UI isn't much on modern
processors. Adding a bunch of API object updates that cause thread
slowdown to the mix that can cause UI stuttering is, again, asking for
trouble.
And how is TableView, Slider, TextField, etc all working just fine but
ComboBox freaks out? What's so special about ComboBox? Is there some
hack I can do to not trigger the exception?
The updating of your “API objects” can and should remain on a
background thread, however once updated the changes which trigger an
update to your UI (changing a value in a bound property) should occur
on the JavaFX thread via Platform.runLater for example.
Doing all this is just messy, inefficient, and duplicating code. It
would involve creating Runnable implementations that does about 10 lines
of code with objects that get updated as fast as they can be with
different object types, resulting in more threads and garbage being
created. Using generic magic isn't really a solution either because
different API objects convert data from String to some other type
depending on the implementation.
Would it not be possible to have a runPlatformListener method that just
runs the ChangeListener on the platform thread automatically? It would
reduce the amount of garbage dramatically since JavaFX only ever fires a
change event if the object is itself different(in other words, if the
current value is 0 and the new value is 0, there is no change) which is
nice and efficient.
Also, take the attitude down a notch or two.
Brian
On Mon, Nov 12, 2018 at 10:02 PM Ty Young <mailto:youngty1...@gmail.com>> wrote:
On 11/12/18 5:39 PM, Tom Schindl wrote:
> Hi,
>
> You are supposed to interact with Nodes who are currently shown
in the
> SG only only the JavaFX Application Thread.
I never touch the GUI in my other threads, ever. The threads simply
change the value of a type stored in a property. The
ChangeListener that
is used is created in the GUI JavaFX thread.
>
> JavaFX although is not checking each and every property (change)
as this
> would be too resource intensive but at sensitive cases (eg when
> interacting with Glass) it does check that you run on the
correct thread.
The update process for updating my API objects is slow(for reasons
beyond my control), so even assuming I somehow manage to magically
update everything in the GUI thread, how the hell do you fix the GUI
stuttering at that point?
Really, having an entire application do all of it's processing on one
thread in 2018 is really just idiotic and asking for trouble.
>
> Even though your TableView, ... updates seem to work you can run
into
> disasterous states - see eg
https://bugs.openjdk.java.net/browse/JDK-8198577
>
> Tom
I'm not sure what the bug is about since the description really
doesn't
give much info however I really haven't noticed anything, even
long term
with it being open for 8+ hours. These objects are update very
frequently as well.
To be clear, this isn't some business application that gets info
from a
database or something.
> On 10.11.18 06:58, Ty Young wrote:
>> Hi,
>>
>>
>> My JavaFX program updates API objects in the background via a
non FX
>> thread that, when changed by another program, are reflected in
my JavaFX
>> GUI's controls by property binding, specifically TableView, Slider,
>> TextField, and ComboBox. Problem is, while JavaFX is OK with
this for
>> TableView, Slider, and TextField, it throws a Not on FX application
>> thread exception *only* for the ComboBox.
>>
>>
>> The code for the slider looks like this:
>>
>> private class ValueListener implements ChangeListener
>> {
>> @Override
>> public void changed(ObservableValue
>> observable, Integer oldValue, Integer newValue)
>> {
>> slider.getSlider().setValue(newValue);
>> slider.getTextBox().setText(newValue.toString());
>> }
>> }
>>
>>
>> (the slider variable is misleading, it's actually a VBox that
contains a
>> Slider and a TextField. Need to change it but I digress.)
>>
>>
>> which works fine. However this:
>>
>>
>> private class ValueListener implements ChangeListener
>> {
>> @Override
>> public void changed(ObservableValue
observable, E
>> old
Re: Bug: Not on FX application thread exception is inconsistent
On 11/12/18 5:39 PM, Tom Schindl wrote:
Hi,
You are supposed to interact with Nodes who are currently shown in the
SG only only the JavaFX Application Thread.
I never touch the GUI in my other threads, ever. The threads simply
change the value of a type stored in a property. The ChangeListener that
is used is created in the GUI JavaFX thread.
JavaFX although is not checking each and every property (change) as this
would be too resource intensive but at sensitive cases (eg when
interacting with Glass) it does check that you run on the correct thread.
The update process for updating my API objects is slow(for reasons
beyond my control), so even assuming I somehow manage to magically
update everything in the GUI thread, how the hell do you fix the GUI
stuttering at that point?
Really, having an entire application do all of it's processing on one
thread in 2018 is really just idiotic and asking for trouble.
Even though your TableView, ... updates seem to work you can run into
disasterous states - see eg https://bugs.openjdk.java.net/browse/JDK-8198577
Tom
I'm not sure what the bug is about since the description really doesn't
give much info however I really haven't noticed anything, even long term
with it being open for 8+ hours. These objects are update very
frequently as well.
To be clear, this isn't some business application that gets info from a
database or something.
On 10.11.18 06:58, Ty Young wrote:
Hi,
My JavaFX program updates API objects in the background via a non FX
thread that, when changed by another program, are reflected in my JavaFX
GUI's controls by property binding, specifically TableView, Slider,
TextField, and ComboBox. Problem is, while JavaFX is OK with this for
TableView, Slider, and TextField, it throws a Not on FX application
thread exception *only* for the ComboBox.
The code for the slider looks like this:
private class ValueListener implements ChangeListener
{
@Override
public void changed(ObservableValue
observable, Integer oldValue, Integer newValue)
{
slider.getSlider().setValue(newValue);
slider.getTextBox().setText(newValue.toString());
}
}
(the slider variable is misleading, it's actually a VBox that contains a
Slider and a TextField. Need to change it but I digress.)
which works fine. However this:
private class ValueListener implements ChangeListener
{
@Override
public void changed(ObservableValue observable, E
oldValue, E newValue)
{
combo.setValue(newValue);
}
}
doesn't for the ComboBox.
Is this a bug or is there some legitimate invisible reason as to why the
slider/textfield isn't throwing an error but the combobox one is?
Re: Bug: Not on FX application thread exception is inconsistent
On 11/9/18 11:58 PM, Ty Young wrote:
Hi,
My JavaFX program updates API objects in the background via a non FX
thread that, when changed by another program, are reflected in my
JavaFX GUI's controls by property binding, specifically TableView,
Slider, TextField, and ComboBox. Problem is, while JavaFX is OK with
this for TableView, Slider, and TextField, it throws a Not on FX
application thread exception *only* for the ComboBox.
The code for the slider looks like this:
private class ValueListener implements ChangeListener
{
@Override
public void changed(ObservableValue
observable, Integer oldValue, Integer newValue)
{
slider.getSlider().setValue(newValue);
slider.getTextBox().setText(newValue.toString());
}
}
(the slider variable is misleading, it's actually a VBox that contains
a Slider and a TextField. Need to change it but I digress.)
which works fine. However this:
private class ValueListener implements ChangeListener
{
@Override
public void changed(ObservableValue observable, E
oldValue, E newValue)
{
combo.setValue(newValue);
}
}
doesn't for the ComboBox.
Is this a bug or is there some legitimate invisible reason as to why
the slider/textfield isn't throwing an error but the combobox one is?
Anything at all on this? Does JavaFX have bipolar thread disorder or
something?
Bug: Not on FX application thread exception is inconsistent
Hi,
My JavaFX program updates API objects in the background via a non FX
thread that, when changed by another program, are reflected in my JavaFX
GUI's controls by property binding, specifically TableView, Slider,
TextField, and ComboBox. Problem is, while JavaFX is OK with this for
TableView, Slider, and TextField, it throws a Not on FX application
thread exception *only* for the ComboBox.
The code for the slider looks like this:
private class ValueListener implements ChangeListener
{
@Override
public void changed(ObservableValue
observable, Integer oldValue, Integer newValue)
{
slider.getSlider().setValue(newValue);
slider.getTextBox().setText(newValue.toString());
}
}
(the slider variable is misleading, it's actually a VBox that contains a
Slider and a TextField. Need to change it but I digress.)
which works fine. However this:
private class ValueListener implements ChangeListener
{
@Override
public void changed(ObservableValue observable, E
oldValue, E newValue)
{
combo.setValue(newValue);
}
}
doesn't for the ComboBox.
Is this a bug or is there some legitimate invisible reason as to why the
slider/textfield isn't throwing an error but the combobox one is?
Re: JavaFX in-memory dynamic CSS file editing and applying
On 10/15/18 7:02 AM, David Grieve wrote:
Just setStyle -fx-theme-header (etc.) on the root node.
That doesn't work, sadly. The actual FX CSS properties that utilize
-fx-theme-header don't update after setting a new value.
On 10/15/18 1:05 AM, Ty Young wrote:
Does JavaFX have an API for dynamically editing and applying CSS
files in-memory? If not, would there be any possibility in one ever
being made?
My reasoning for such an API is, instead of switching between
completely separate CSS files and having to update each whenever I
need to support a new component, I'd like the ability to just have 1
CSS file and edit it's values in-memory and have it reflected in
JavaFX as soon as the change is made. For example instead of changing
the individual components themselves I'd like to get all of this:
*
{
-fx-theme-header: #44;
-fx-theme-background: #3D3D3D;
-fx-theme-background-alt: #2E2E2E;
-fx-theme-selected: #F0544C;
-fx-theme-label-text: #D2D2D2;
-fx-theme-selectable-hover: #454545;
-fx-theme-tab-close-color: -fx-theme-label-text;
-fx-highlight-fill: -fx-theme-selected;
}
and modify it via a JavaFX API to change it to something like:
*
{
-fx-theme-header: #FF;
-fx-theme-background: -fx-theme-header;
-fx-theme-background-alt: #F2F2F2;
-fx-theme-selected: #CBEAFF;
-fx-theme-label-text: #33;
-fx-theme-selectable-hover: #E1E1E1;
-fx-theme-tab-close-color: -fx-theme-label-text;
-fx-highlight-fill: -fx-theme-selected;
}
Since these are used throughout the CSS file, all the components that
use these will be updated.
JavaFX in-memory dynamic CSS file editing and applying
Does JavaFX have an API for dynamically editing and applying CSS files
in-memory? If not, would there be any possibility in one ever being made?
My reasoning for such an API is, instead of switching between completely
separate CSS files and having to update each whenever I need to support
a new component, I'd like the ability to just have 1 CSS file and edit
it's values in-memory and have it reflected in JavaFX as soon as the
change is made. For example instead of changing the individual
components themselves I'd like to get all of this:
*
{
-fx-theme-header: #44;
-fx-theme-background: #3D3D3D;
-fx-theme-background-alt: #2E2E2E;
-fx-theme-selected: #F0544C;
-fx-theme-label-text: #D2D2D2;
-fx-theme-selectable-hover: #454545;
-fx-theme-tab-close-color: -fx-theme-label-text;
-fx-highlight-fill: -fx-theme-selected;
}
and modify it via a JavaFX API to change it to something like:
*
{
-fx-theme-header: #FF;
-fx-theme-background: -fx-theme-header;
-fx-theme-background-alt: #F2F2F2;
-fx-theme-selected: #CBEAFF;
-fx-theme-label-text: #33;
-fx-theme-selectable-hover: #E1E1E1;
-fx-theme-tab-close-color: -fx-theme-label-text;
-fx-highlight-fill: -fx-theme-selected;
}
Since these are used throughout the CSS file, all the components that
use these will be updated.
Re: Some visual issues with a test application
On 10/14/18 3:22 PM, Mark Raynsford wrote: Hello! I've been developing with Swing for many years, and I'm just now giving JavaFX a serious look now that the distribution issues are fixed (packages on Maven Central and the like). I've run into a couple of odd issues and I'm not sure that either of them are my fault. I've been putting together a little API and GUI application for browsing OSGi repositories: https://github.com/io7m/osgibrowse I've recorded the issues here: http://ataxia.io7m.com/2018/10/14/javafx.mp4 You may notice that things look a little odd in that all windows appear to be fullscreen. This is because I'm using a tiling window manager (i3). Historically, Swing had a bit of trouble with this sort of window manager. I'm not sure if JavaFX also does. The first issue: The menu bar I created seems to behave erratically. Sometimes I can click on the menu to open it, other times it flashes open and then immediately closes. In both cases, the menu seems to be detached from the menu bar (there's a gap between the menu and the bar). The menu is created here and added to a BorderPane: https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBBrowserWindow.java#L30 The second issue: Icons set on TreeItem values seem to be corrupted when the TreeTableView containing them is scrolled. You can see this happen in the video. The table in question is populated from an immutable snapshot of data returned by the underlying repository API. Once a repository is added, the table is populated once and then does not change until the user adds another repository. Double clicking on a row "selects" a bundle from the repository and this triggers a refresh of the table view. When I scroll up and down, it seems like icon views are incorrectly reused from other rows. The entirety of the table configuration happens here: https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBTableView.java#L188 Icons are set on the tree table nodes here: https://github.com/io7m/osgibrowse/blob/develop/com.io7m.osgibrowse.gui.javafx/src/main/java/com/io7m/osgibrowse/gui/javafx/OBTableView.java#L92 Any advice would be appreciated. The code ultimately does everything correctly. Some JavaFX components expose a getChildren() method which doesn't actually do anything because your supposed to use getItems() or something like that and it causes odd behavior but you're using the right methods... but I digress, JDK 11 switched to GTK3 by default which has caused some bugs. Try setting: -Djdk.gtk.version=2 wherever you add run args in your Maven project(I use Ant and have no experience with Maven). It will force GTK2. I tried to run your program myself but there doesn't seem to be a way to add local dependencies like you can with Ant in Netbeans 9, causing a build fail and Netbeans 9 can't find a main class. "YOU ARE NOT USING THE API CORRECTLY" criticism is also welcome. If I may ask, why are you sidestepping constructors and using static everywhere? It works all the same, just never seen anyone write code the way you did.
Re: Filling the Packager gap
On 9/27/18 1:44 AM, Johan Vos wrote: Hi Ty, Apart om jdk.jlink, who else is exporting jdk.tools.jlink.internal.packager ? If that is the case, there must be something wrong. The 12-sandbox version also exports that package: http://hg.openjdk.java.net/jdk/sandbox/file/6972c0e75e23/src/jdk.jlink/share/classes/module-info.java - Johan JavaFX itself is: rt/apps/performance/JavaFX/src/jdk.jlink/classes(It's just an app) module-info.java.extra from /rt/dependencies/jdk.jlink module-info.java.extra from /rt/build/modular-sdk/modules_src/jdk.jlink I don't know what the .extra is all about. I found those by searching for all the module-info files from in JavaFX and seeing if there was any matches to jdk.tools.jlink.internal.packager. On Thu, Sep 27, 2018 at 4:14 AM Ty Young <mailto:youngty1...@gmail.com>> wrote: On 9/19/18 3:55 AM, Johan Vos wrote: > Hi, > > As promised, we looked into an interim solution for the packager-gap. Work > for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. > We backported the required changes to an OpenJDK 11 mirror: > https://github.com/johanvos/openjdk-mobile11/tree/packager > > With this, we created modified OpenJDK 11 builds that contain the packager > (wrapper/exe + module including native library). They can be downloaded and > tested/used at > > http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip > http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip > > For Windows, you have to unzip the bundle in the same directory as the JDK, > as the packager wrapper expect to find the java binary at the same level. > > Note that these are not products. We use them internally to create > installers (e.g. we're using them for Scene Builder 11 and that works > fine), and they do what we expect them to do, but there are no guarantees > of course so at least for now I recommend using them in development only > (or even better, look at the changes and contribute to > https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) > > - Johan The JDK source fails to compile due to a duplicate qualified export. Removing the export from openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java fixes it. By the way, how does one use this with jLink generated by Netbeans? I used the jLink build as the input and it just dumped it into the "app" folder when making the image which doesn't work.
Re: Filling the Packager gap
On 9/19/18 3:55 AM, Johan Vos wrote: Hi, As promised, we looked into an interim solution for the packager-gap. Work for the new Java Packager (12?) is being done in the OpenJDK sandbox repo. We backported the required changes to an OpenJDK 11 mirror: https://github.com/johanvos/openjdk-mobile11/tree/packager With this, we created modified OpenJDK 11 builds that contain the packager (wrapper/exe + module including native library). They can be downloaded and tested/used at http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip For Windows, you have to unzip the bundle in the same directory as the JDK, as the packager wrapper expect to find the java binary at the same level. Note that these are not products. We use them internally to create installers (e.g. we're using them for Scene Builder 11 and that works fine), and they do what we expect them to do, but there are no guarantees of course so at least for now I recommend using them in development only (or even better, look at the changes and contribute to https://bugs.openjdk.java.net/browse/JDK-8200758 or to this backport) - Johan The JDK source fails to compile due to a duplicate qualified export. Removing the export from openjdk-mobile11-packager/src/jdk.jlink/share/classes/module-info.java fixes it. By the way, how does one use this with jLink generated by Netbeans? I used the jLink build as the input and it just dumped it into the "app" folder when making the image which doesn't work.
Re: BUG: zip file in sdk lib folder causes bugged JDK build
On 9/22/18 9:01 AM, Kevin Rushforth wrote: I have never seen this problem. As for including src.zip in the "lib" directory, that matches what the JDK has done for years. It may have something to do with how you are building your JDK? No, I compile JavaFX the same everytime - remove -Werror from the Linux gradle file and ignore all web tests via -x :web:test. Maybe something was changed on the JDK side of things(an exclude list maybe)? I don't remember having this issue before either compiling the pre-release versions of JDK11 and JavaFX either. I used both the JDK11 and JavaFX 11 release branch for the source code. In any case, as mentioned in a previous email, I do not recommend using a boot JDK with JavaFX modules to build FX. This is no longer the expected way to build FX and will quite likely stop working at some point. -- Kevin Why exactly does having the modules in the JDK matter? Worse case scenario they just aren't used, right? Even if it isn't the "expected" way to build JavaFX, it still has advantages over using the standalone SDK and IMO should still be supported. I'm having a hard time understanding why people at Oracle(or Oracle itself) seems to just want to drop features/tools/options and replace them with completely inferior, incomplete, or not as good replacements, like jLink(though the reduced file size is useful). You all must realize that by doing this that you are breaking projects that utilized these features/tools/options(like JPackager) and increasing the amount of work for IDE developers as they have to support whatever feature that is supported on JDK release X but not on release Y(they have to do this anyway for new language features, but why complicate more?). To add salt to the wound, non LTS releases are only supported until the next JDK so you need to adapt your project for every few releases because of this. Netbeans *still* doesn't have a way to convert a non modular JavaFX application(where JPackager would've been used) to a modular one easily, and modules were released with *Java 9* and many third party libraries still haven't moved to modules yet either(not that I use them, I've just read elsewhere that they haven't). I literally have a non modular JavaFX program that used to use jPackager that doesn't even compile anymore because Apache Netbeans 9 still hasn't added any code to remove jPackager from the ant scripts(or whatever). The project isn't worth anything but that isn't the point. Why break support for it if it isn't hurting anything? Why introduce something and then abort it like it's an unwanted baby? Isn't developing these features/tools/options and dropping them so fast costing time and money? If there is a completely legitimate reason like is the case with Swing interop(as stated before) then that's understandable, but some minor bug(like above) that could probably easily be fixed is just kicking yourselves. No one wants to utilize a feature/tool/option only for it to be pulled from under them all of a sudden for no good reason or a *PROPER* AND *COMPLETE* replacement. It happens so often you can't depend on any new feature/tool/option since you have no idea if it isn't just going to get removed a few JDK releases later. And no, a standalone SDK isn't a replacement for a JDK that has built in support for JavaFX. Does it continue to allow you to compile the project? Maybe? At what cost? HDD space, memory(see below), convenience, and reproducibility(multiple JavaFX versions potentially being used). I didn't even know about it until I compiled and tested it, but a "client" build of the JDK uses less memory than a "server" variant regardless of the application itself. Without being able to build JDK with JavaFX support baked in, my application would be unnecessarily allocating more memory than it needs to. Most JDK/JRE builds are "server" builds and not "client" builds and use around 250MB which is insane and will cause people to complain. If there is no other *PROPER* AND *COMPLETE* way to reduce the insanely high memory usage of "server" JDK/JRE builds, is that use case not enough reason to support it? (Side note: A "client" build of the JDK fails to finish a JavaFX test because it runs out of heap space. Guess I'll need to build a server and client variants from now on.) On 9/18/2018 7:30 PM, Ty Young wrote: The zip file "src.zip" located in rt/build/sdk/lib/ after building JavaFX from source causes a bugged build of OpenJDK with JavaFX integrated into it. The build itself completes just fine, it's just that resulting build has issues. Because a zip file isn't a supported module format, Netbeans spits out an error saying as such when attempting to compile a JavaFX application(unsure if the project being modular matters here or not, but it is.). It also seems to cause
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
On 9/24/18 2:12 AM, Johan Vos wrote: > And it's only going to get worse as time goes on. Would it not be > possible to support up until the last JDK LTS(Starting at 11) release > for building JavaFX? I feel like maybe that would be more reasonable. This is a good question, and maybe in the future we might not be so quick to do this...or maybe we will. We should discuss this before we get to this point for JavaFX 13, a little less than six months from now. The choices for the model are: 1. Allow building JavaFX N with either JDK N-1 or JDK N. 2. Allow building JavaFX N with the most recent LTS or later. Choice #1 will allow JavaFX to better keep pace with JDK features (API or language features). Choice #2 will allow JavaFX to build and run with the most current, stable JDK LTS at the cost of not being able to use newer JDK features. One of the reasons Java is moving to a fast release cadence is because today, this is required to stay relevant in a fast-changing landscape. I think we need to do the same with JavaFX. We should be able to leverage the latest and greatest advances in the JDK, since this will allow JavaFX to move fast as well, which is required to stay relevant. Maybe it's because I don't work for a large corporation, but I don't see this supposed "fast-changing" landscape. To me, it just looks like Java is trying to appeal to all the people from Python/C++/other languages who can't or have a hard time writing object oriented code by introducing a more lazy "functional" and "concise" way of programming. The amount of actual meaningful updates to the language in 10 and 11 in my eyes is fairly small, which is somewhat expected with the faster release cycles. If there was actually a "fast-changing" landscape, I would think that there would more meaningful and useful updates rather than the 50/50 "functional and/or concise"/other misc updates that has been the case for JDK 10 and 11. Personally, whatever was updated that resulted in Netbeans properly using the OS's Look and Feel was the only worthwhile update of the entire JDK 11 release IMO, but I digress. To be clear, I'm not that concerned about breaking compatibility with older versions of the JDK because of API updates/introductions/removals or new, better tools being introduced. I'm more concerned about backwards compatibility being broken for stupid reasons like new lazy language updates that have no actual value or can be done with older compatible ways just because people want to be lazy, "functional", and "concise" which has become a bit of a hot trend lately. If you want to run on the latest stable JDK LTS, the logical consequence seems to me you use the latest stable JavaFX LTS. There is LTS support available for both Java and JavaFX 11 and they are pretty well aligned. That's all fine and dandy except for the fact that you can't guarantee what JRE is being run if you haven't moved to Java 9 modules. What do you do, wait a few months after a new LTS is out and then update your application with new JDK/JavaFX features and say "tough luck" to anyone who is still using a previous LTS? What if a user has a newer JRE installed with a feature that exists on the previous LTS removed but not their newer JRE that JavaFX LTS depends on? I've never tried it, but I guess you could prompt the user to download a compatible JRE via a Swing GUI and use that to launch the application via a launcher... but that's just awful for so many different reasons. Having said that, there is no point in moving forward just for the fun of it. We also have to distinguish between changes in the VM or in the core Java API's. My opinion is that if a new feature is added to JDK N, we can really take advantage of it in JavaFX (N+1). In some cases, there won't be new features relevant to OpenJFX. But even then, I don't think we can't change our rules on a per-release case (e.g. JavaFX 14 works with Java 13 and Java 14, and even Java 12; but JavaFX 15 works with Java 14 and Java 15 and not with Java 13). In general, I think developers updating from JavaFX 11-12-13 are also capable of updating the JDK from 11-12-13, so I prefer the coupling 1. Allow building JavaFX N with either JDK N-1 or JDK N. - Johan
Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11
On 9/21/18 5:27 PM, Kevin Rushforth wrote: Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8209966 https://github.com/javafxports/openjdk-jfx/pull/174 This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11. -- Kevin Is requiring the previously released JDK to build JavaFX really necessary? Does something *actually* break as a result of using an older boot JDK? If not, this is just going to make compiling JavaFX a real pain as you need to compile(or somehow find) a JDK that is one version behind, and if you don't have it then you need to compile the JDK with JavaFX before that(and repeat). In other words, if I wanted to compile JavaFX 12 right now I'd need to use Oracle JDK 10(which may not even be available for download in the future, who knows?), use it to compile JDK 11 with JavaFX 11, and then use that to compile JavaFX 12 if I couldn't find JDK 11 with JavaFX online somewhere. And it's only going to get worse as time goes on. Would it not be possible to support up until the last JDK LTS(Starting at 11) release for building JavaFX? I feel like maybe that would be more reasonable. Thanks.
Re: BUG: TableView's setMouseTransparent method does not make mouse transparent
On 9/19/18 10:27 AM, Kevin Rushforth wrote: JavaFX does not use exclusive full-screen mode. It simulates full screen by using an undecorated window that is exactly the size of the screen. This means that pop-ups, such as those used by ComboBox and content menus, will continue to work (they use separate windows). -- Kevin Well, that kind of stinks. Regarding the bug itself, I've figured out that it's a GTK3 bug as hinted on the bug report[1]. Switching to GTK2 via the suggested argument fixes the bug for me. BTW, have you had a chance to read the other email I sent about the zip file causing a bugged JDK? [1] https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8211007 On 9/19/2018 7:52 AM, Ty Young wrote: On 9/19/18 8:01 AM, Kevin Rushforth wrote: Thanks for reporting the issue. I see it in the bug system, and it should be transferred to the JDK project in JBS in a day or so. I'm not sure I understand your question: > (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?) What do you mean by "render the desktop" ? -- Kevin Typically when a game(or potentially any 3d application) is fullscreen, that game(or 3d application) has exclusive control and desktop elements(the desktop environment and the windows within) are no longer rendered. As a result, frame rate is increased, latency is reduced, and stuttering/jittering are reduced or non existent. However, it's possible to "fake" fullscreen by using borderless windowed mode which does not provide the performance benefits of fullscreen while being 'fullscreen". Basically what I'm asking is: Does JavaFX just disable window decorations(title bar/resize borders) and overlays the application over the OS's desktop or is it *truly* fullscreen? On 9/18/2018 7:11 PM, Ty Young wrote: Bug review ID: 9057302. TavleView's setMouseTransparent no longer makes mouse events(like clicking) transparent for that TableView when set to true in JavaFX 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling OpenJDK 10 with JavaFX integrated and had the same issue even though Oracle 10 did not have the bug. I personally use this to create an On Screen Display for displaying some GPU information while playing games in Linux(Yes, I know it's incredibly bad to do that since the desktop is still being rendered). Because of this bug, in-game menus cannot be clicked if they are in the top left corner(where the window is) as the mouse transparent method is no longer working. (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?)
Re: BUG: TableView's setMouseTransparent method does not make mouse transparent
On 9/19/18 8:01 AM, Kevin Rushforth wrote: Thanks for reporting the issue. I see it in the bug system, and it should be transferred to the JDK project in JBS in a day or so. I'm not sure I understand your question: > (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?) What do you mean by "render the desktop" ? -- Kevin Typically when a game(or potentially any 3d application) is fullscreen, that game(or 3d application) has exclusive control and desktop elements(the desktop environment and the windows within) are no longer rendered. As a result, frame rate is increased, latency is reduced, and stuttering/jittering are reduced or non existent. However, it's possible to "fake" fullscreen by using borderless windowed mode which does not provide the performance benefits of fullscreen while being 'fullscreen". Basically what I'm asking is: Does JavaFX just disable window decorations(title bar/resize borders) and overlays the application over the OS's desktop or is it *truly* fullscreen? On 9/18/2018 7:11 PM, Ty Young wrote: Bug review ID: 9057302. TavleView's setMouseTransparent no longer makes mouse events(like clicking) transparent for that TableView when set to true in JavaFX 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling OpenJDK 10 with JavaFX integrated and had the same issue even though Oracle 10 did not have the bug. I personally use this to create an On Screen Display for displaying some GPU information while playing games in Linux(Yes, I know it's incredibly bad to do that since the desktop is still being rendered). Because of this bug, in-game menus cannot be clicked if they are in the top left corner(where the window is) as the mouse transparent method is no longer working. (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?)
BUG: zip file in sdk lib folder causes bugged JDK build
The zip file "src.zip" located in rt/build/sdk/lib/ after building JavaFX from source causes a bugged build of OpenJDK with JavaFX integrated into it. The build itself completes just fine, it's just that resulting build has issues. Because a zip file isn't a supported module format, Netbeans spits out an error saying as such when attempting to compile a JavaFX application(unsure if the project being modular matters here or not, but it is.). It also seems to cause any attempt to build a new build of OpenJDK to segmentation fault using that same bugged JDK as the boot jdk. Is there somekind of special exception for unsupported module formats for the standalone SDK or is it just manually removed after it's done being compiled? Not sure if it's worth creating a bug report for this since this seems to be some minor mishap. Including a zipped file of the source code in a lib file doesn't make a whole lot of sense to me... I would think it should be in the parent directory(rt/buid/sdk), next to the legal and lib folders.
BUG: TableView's setMouseTransparent method does not make mouse transparent
Bug review ID: 9057302. TavleView's setMouseTransparent no longer makes mouse events(like clicking) transparent for that TableView when set to true in JavaFX 11. In Oracle 9 and 10 it did, however. I vaguely remember compiling OpenJDK 10 with JavaFX integrated and had the same issue even though Oracle 10 did not have the bug. I personally use this to create an On Screen Display for displaying some GPU information while playing games in Linux(Yes, I know it's incredibly bad to do that since the desktop is still being rendered). Because of this bug, in-game menus cannot be clicked if they are in the top left corner(where the window is) as the mouse transparent method is no longer working. (While i'm at it, does JavaFX *always* render the desktop even if a JavaFX application is fullscreen?)
Re: Table Input
On 06/19/2018 10:51 AM, omnip...@gmail.com wrote: A minor issue in the Table component existed in previous versions of JavaFX when editing in a cell was turned on. Only if the Return key was pressed was the data entered into the backing bean. Leaving the cell with Tab or by mouse did not register the change. I thought just when a cell looses focus it should trigger updating the bean. I have not looked at the recent builds but I thought I'd ask if it has come up on anyone's radar. I noticed it when I moved from teaching Swing to FX. Ken Fogel IIRC, this isn't specific to Table. A spinner with editing enabled also does this and it breaks events(onKeyTyped does nothing).
Re: OpenJFX status update
On 05/16/2018 02:04 PM, Kevin Rushforth wrote: On 5/16/2018 10:49 AM, Ty Young wrote: That one, as mentioned in the wiki build guide. I get an immediate build fail(see: https://pastebin.com/geR4LLMm). The JDK works just fine: I can set it as the default JDK, run Netbeans, set the project source to 11, and my application builds just fine. Ah, I see. You didn't say what version of gradle or JDK you were using, but this looks like a known problem in trying to run gradle with JDK 11. See: https://github.com/gradle/gradle/issues/4860 https://bugs.openjdk.java.net/browse/JDK-8199069 This is marked as fixed in gradle 4.8-rc1, but I haven't confirmed this. I have every Oracle JDK and OpenJDK version from 8 and above installed. I had assumed that Oracle JDK(s) were required because they were the only ones that would work as OpenJDK 9 and 10 builds in Arch Linux don't support JavaFX and using a self compiled JDK 11 isn't possible due to that bug. I'm using Gradle 4.7 and Oracle JDK 10 to build. And could the new standalone modules be integrated with the source code somehow so that a JDK without JavaFX support can be compiled? Not sure what you mean, but you can use an OpenJDK without modules + the JavaFX standalone modules to build and run your program. It's an option, sure. My problem with it is that it creates so much unnecessary disk usage because each bundled application requires it's own copy of JavaFX. If you had 10 standalone JavaFX applications it would be 1GB easily if they where all modular projects, which are around 106MB for me. Creating an app bundle using classpath is around 200MB(post JDK 8 was 250+ IIRC). One option for you would be to use jlink to create a jre image that includes the javafx modules. This week's openjfx-11-ea+14 build will have a jmods bundle that you can use for this purpose. So like it was done with OpenJDK 8 overlay but just with modules instead, basically? As I wrote before and am still having issues with, after a successful first compile, JavaFX no longer compiles in Arch Linux for me. Any attempt to do so results in a bunch of warning messages(see: https://pastebin.com/rJqu7Nws) which cause the build to fail due to warnings being treated as errors(Should they even be ignored?). In addition. I'm now getting a GCC warning about XIMProc returning an int when it should return void (*). I don't know C or the native APIs so right now I'm at a loss of what to do besides trying to compile on another distro - which is something I *really* would prefer not to have to do. What gcc version are you using? And what Linux distro? 8.1.0 and Arch Linux(Antergos which is basically Arch Linux). That's not a distro I'm familiar with, but it may or may not be related to the issue you are seeing. The gcc errors may be related to compiling with a more-strict 8.1 compiler; we have tested with up to gcc 7.3, but nothing newer than that. A quick look suggests that we will need some way to suppress that warning. For now, you can modify buildSrc/linux.gradle and remove the "-Werror" flag from LINUX.glass.glassgtk2.ccFlags (ditto for gtk3). Arch Linux uses the rolling release update model, so it usually gets the newest software before any other Linux distro. Removing -Werror from those two lines got me a compile, though with many more warnings. However, attempting to compile an OpenJDK with JavaFX results in its own build fail due to jdk packager module being missing in the JavaFX build. See: https://pastebin.com/MzFLDxgK I tried copying the modular src files from a previous build and pasting them into the new one that doesn't have it and now I just get a build fail saying that JDK packager is marked for deprecation. I take it JDK Packager is in the process of being removed then? -- Kevin -- Kevin
Re: OpenJFX status update
On 05/16/2018 10:42 AM, Kevin Rushforth wrote: On 5/15/2018 11:57 PM, Ty Young wrote: 3. JavaFX has been removed from JDK 11 as of this week. Starting with jdk-11+14, early access builds of JDK 11 will not include JavaFX. I'm not sure if it's intentional or perhaps a bug on my end, but I cannot compile JavaFX without Oracle JDK(9 or 10). Attempting to do so with a self compiled JDK with JavaFX support results in a build fail while doing it without JavaFX entirely results in a fail due to Observable classes being missing. Is Oracle JDK a requirement for building JavaFX currently or is this just some weird bug with my compiled JDK? This is likely something on your end, since we build the standalone JavaFX using OpenJDK 10. What repo are you building from? The correct repo is: http://hg.openjdk.java.net/openjfx/jfx-dev/rt That one, as mentioned in the wiki build guide. I get an immediate build fail(see: https://pastebin.com/geR4LLMm). The JDK works just fine: I can set it as the default JDK, run Netbeans, set the project source to 11, and my application builds just fine. And could the new standalone modules be integrated with the source code somehow so that a JDK without JavaFX support can be compiled? Not sure what you mean, but you can use an OpenJDK without modules + the JavaFX standalone modules to build and run your program. It's an option, sure. My problem with it is that it creates so much unnecessary disk usage because each bundled application requires it's own copy of JavaFX. If you had 10 standalone JavaFX applications it would be 1GB easily if they where all modular projects, which are around 106MB for me. Creating an app bundle using classpath is around 200MB(post JDK 8 was 250+ IIRC). As I wrote before and am still having issues with, after a successful first compile, JavaFX no longer compiles in Arch Linux for me. Any attempt to do so results in a bunch of warning messages(see: https://pastebin.com/rJqu7Nws) which cause the build to fail due to warnings being treated as errors(Should they even be ignored?). In addition. I'm now getting a GCC warning about XIMProc returning an int when it should return void (*). I don't know C or the native APIs so right now I'm at a loss of what to do besides trying to compile on another distro - which is something I *really* would prefer not to have to do. What gcc version are you using? And what Linux distro? 8.1.0 and Arch Linux(Antergos which is basically Arch Linux). -- Kevin
Re: OpenJFX status update
3. JavaFX has been removed from JDK 11 as of this week. Starting with jdk-11+14, early access builds of JDK 11 will not include JavaFX. 4. After jdk-11+14 is posted on java.net, and FX is no longer included in JDK 11, we will start using openjfx-11 as the fix version in JBS to distinguish it from JDK 11. We still expect to do a release of JavaFX 11 around the same time as JDK 11, but using a different release number will help track the actual content of JavaFX 11 separately from JDK 11. I'm not sure if it's intentional or perhaps a bug on my end, but I cannot compile JavaFX without Oracle JDK(9 or 10). Attempting to do so with a self compiled JDK with JavaFX support results in a build fail while doing it without JavaFX entirely results in a fail due to Observable classes being missing. Is Oracle JDK a requirement for building JavaFX currently or is this just some weird bug with my compiled JDK? And could the new standalone modules be integrated with the source code somehow so that a JDK without JavaFX support can be compiled? 5. Once this settles down, possibly later this week, I hope to restart the discussion about OpenJFX policies, etc. I also hope to be a bit more responsive over the coming days / weeks than I have been for the last 3-4 weeks. Getting the standalone OpenJFX working and removing JavaFX from the JDK was quite time consuming as you can probably imagine. If you have any general comments or questions about any of this, please reply to this thread. We may want to split out more detailed discussions into their own thread to make it easier to follow. As I wrote before and am still having issues with, after a successful first compile, JavaFX no longer compiles in Arch Linux for me. Any attempt to do so results in a bunch of warning messages(see: https://pastebin.com/rJqu7Nws) which cause the build to fail due to warnings being treated as errors(Should they even be ignored?). In addition. I'm now getting a GCC warning about XIMProc returning an int when it should return void (*). I don't know C or the native APIs so right now I'm at a loss of what to do besides trying to compile on another distro - which is something I *really* would prefer not to have to do.
Building from source fails due to treat warnings as errors
Hi, I'm no longer able to build from any source(dev or 10 atleast) on Arch Linux due to the following warnings here: https://pastebin.com/rJqu7Nws The only two packages that have changed since my last successful source build was Gradle and Mercurial(distro package versions). I've tried downloading an older version of Gradle(version 4.3.1) but the warnings that prevent me from building still show up. Ant version is 1.9.7 but I've built using it before and it worked just fine before. Is there a way I can just ignore these warnings via Wno-error arg? Thanks.
Announcing EA builds of standalone JavaFX SDK
This works just as well as a build of OpenJDK 11 with JavaFX prebuilt for me in Netbeans 9 Beta. The project tested on was a personal modular JavaFX application using OpenJDK 10 in Arch Linux. That said however, there seems to be a bug in the latest release of OpenJFX that is reproducible on my end in both this(standalone library release) as well my OpenJDK 11 OpenJFX build with TableView's setMouseTransparent method no longer working. Using Oracle JDK 10 works as expected. Is this a known issue with the latest release?
