From btkoles at gmail.com Wed Jul 2 02:45:45 2025 From: btkoles at gmail.com (Brandon) Date: Tue, 1 Jul 2025 20:45:45 -0600 Subject: JDK-8360597 - MediaPlayer: Idle Wake Ups 200-400ms. Hundreds and thousands of threads running? Message-ID: The recent JDK-8360597 issue was closed as "Cannot Reproduce" and is waiting for some proof from jstack output. I'm not the reporter of the issue, but it may help to know that the issue was reported after some discussion on Stack Overflow: https://stackoverflow.com/questions/79666915/javafx-mediaplayer-why-are-hundreds-and-thousands-of-threads-running There might be some helpful information for reproducing the issue there. - Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From notzed at gmail.com Fri Jul 18 11:22:23 2025 From: notzed at gmail.com (Michael Zucchi) Date: Fri, 18 Jul 2025 20:52:23 +0930 Subject: JDK-8210547[linux] Uncontrolled framerate Message-ID: <9ccc6f82-a474-409d-940a-930a8cadfd01@gmail.com> Morning, I think i've [1], on a couple of systems [2,3] and with no-where else to communicate that I'm writing to the list.? If it matters both are using the amdgpu driver, xfce4, and X.org with tearfree enabled, with or without a compositor.? It manifests itself as the window updating at an uncapped framerate, high cpu use, etc. It was from using a Transition animation with the default frame-rate. From what I can tell it's due to PaintCollector.done() calling QuantumToolkit.vsyncHint() which always calls postPulse() which usually calls the pulse handler for whatever reason (animation is active?) - which re-runs the animation, which re-triggers and update, and so on. If I simply comment out the invocation of postPulse() in vsyncHint() then the animation defaults to a sort-of 60hz.? The timing isn't very accurate and has fairly regular (bit ugly) jumps - although this also happens if I use a rate that matches my screens which don't run at 60. Looking through QuantumToolkit and related stuff I can't see anything obvious, it seems like that's the way it's supposed to work?? Unless redraws are being retriggered when they shouldn't be.? Even the trivial example below shows it - Hello spins at a wild rate. I've got a lot of time on my hands so can look into it, if there's anything to look into? Regards, ?Michael [1] https://bugs.openjdk.org/browse/JDK-8210547 [2] gentoo, liunux 6.12.36, AMD Ryzen 4700U APU. [3] slackare64-current linux 6.12.29, Ryzen 3900X, Radeon HD7970. -- simple example : ? ? ? ? ? ? Group g = new Group(new Text("Hello")); ? ? ? ? ? ? g.setTranslateX(100); ? ? ? ? ? ? g.setTranslateY(100); ? ? ? ? ? ? root.getChildren().setAll(g); ? ? ? ? ? ? Transition anim = new Transition() { ? ? ? ? ? ? ? ? double arg = 0; ? ? ? ? ? ? ? ? { ? ? ? ? ? ? ? ? ? ? setCycleCount(INDEFINITE); ? ? ? ? ? ? ? ? ? ? setCycleDuration(Duration.seconds(1)); ? ? ? ? ? ? ? ? } ? ? ? ? ? ? ? ? @Override ? ? ? ? ? ? ? ? protected void interpolate(double frac) { ? ? ? ? ? ? ? ? ? ? g.setRotate(arg++); ? ? ? ? ? ? ? ? } ? ? ? ? ? ? }; ? ? ? ? ? ? anim.play(); -------------- next part -------------- An HTML attachment was scrubbed... URL: From pfurbacher at mac.com Wed Jul 23 03:21:57 2025 From: pfurbacher at mac.com (Paul Furbacher) Date: Tue, 22 Jul 2025 23:21:57 -0400 Subject: Is there an easier way to "fix" a control instead of building everything (i.e., java, native, etc.)? Message-ID: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com> I want to investigate fixing what I consider a bug or deficiency in a particular control in the easiest manner possible. Initially, I thought to just build everything, but that hasn?t worked because I run into an issue with native compilation, notably in ?:graphics:ccMacGlass?. Instead of battling gradle to build the whole shebang, it seems to me it would be much quicker to simply patch an existing distribution. Browsing ?build.gradle?, nothing jumps out at me. Is it possible to just patch a published distribution with a ?fixed? javafx.controls jar? (Leave jmods out of the picture for the moment because I?ll initially use javafx on the classpath. If my idea of a fix pans out, then I?d proceed with filing a bug report with suggested changes, and maybe doing a pull request ? that?s for later.) If that?s not possible, I might be back here asking for help diagnosing what?s causing clang to finish with a non-zero exit value Regards, Paul Furbacher From kevin.rushforth at oracle.com Wed Jul 23 13:34:18 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 23 Jul 2025 06:34:18 -0700 Subject: Is there an easier way to "fix" a control instead of building everything (i.e., java, native, etc.)? In-Reply-To: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com> References: <2CA86055-26DF-41AB-A6B5-BB015203E69A@mac.com> Message-ID: [redirecting to openjfx-dev] You will need to build all of JavaFX using gradle. You might be running into an issue with the version of Xcode you are using. You will need macOS 14 or 15 with a recent version of Xcode. We use Xcode 15.4 for our production builds. Can you list the version of macOS and Xcode you are using? And copy/paste the specific error message(s) you see? -- Kevin On 7/22/2025 8:21 PM, Paul Furbacher wrote: > I want to investigate fixing what I consider a bug or deficiency in a particular control in the easiest manner possible. > > Initially, I thought to just build everything, but that hasn?t worked because I run into an issue with native compilation, notably in ?:graphics:ccMacGlass?. > > Instead of battling gradle to build the whole shebang, it seems to me it would be much quicker to simply patch an existing distribution. Browsing ?build.gradle?, nothing jumps out at me. > > Is it possible to just patch a published distribution with a ?fixed? javafx.controls jar? > > (Leave jmods out of the picture for the moment because I?ll initially use javafx on the classpath. If my idea of a fix pans out, then I?d proceed with filing a bug report with suggested changes, and maybe doing a pull request ? that?s for later.) > > If that?s not possible, I might be back here asking for help diagnosing what?s causing clang to finish with a non-zero exit value > > > Regards, > > Paul Furbacher > From pfurbacher at mac.com Fri Jul 25 02:30:55 2025 From: pfurbacher at mac.com (Paul Furbacher) Date: Thu, 24 Jul 2025 22:30:55 -0400 Subject: Is there an easier way to "fix" a control instead of building everything (i.e., java, native, etc.)? Message-ID: <5025C7BA-12B4-4951-BFBD-214CDA5C63F8@mac.com> Thanks everyone for the various pieces of advice. Switching to the master branch (I had been using jfx21) resolved the problem with clang failing to compile :graphics:ccMacGlass. That yielded a successful build. Turns out, when I ran my simple demo of the problem against the build, the incorrect behavior didn?t manifest itself. I began to doubt what I had seen in jfx21, but rerunning using jfx21, it was there: a buried exception which was leaving the date picker textfield with an invalid value when typed and committed by the user. That?s when, after crafting a number of unsuccessful searches in JBS, I finally found the issue (https://bugs.openjdk.org/browse/JDK-8303478) and that it had been resolved in jfx22. So, all I have to do is upgrade my much larger apps that use the DatePicker to at least jfx22. Again, thanks for all the help, although I wasn't able to get John Hendrikx?s approach (I?m using gradle, and couldn?t figure out how to get it to put my versions of the javafx classes first on the class path). Best regards, Paul Furbacher From perini.davide at dpsoftware.org Tue Jul 29 13:06:47 2025 From: perini.davide at dpsoftware.org (Davide Perini) Date: Tue, 29 Jul 2025 15:06:47 +0200 Subject: JDK24 WARNING: Please consider reporting this to the maintainers of class com.sun.marlin.OffHeapArray Message-ID: <26111975-94af-44bc-8749-327972b0efbe@dpsoftware.org> Using JDK 24.0.2 and JavaFX 24 I get a lot of warnings: WARNING: A terminally deprecated method in sun.misc.Unsafe has been called WARNING: sun.misc.Unsafe::allocateMemory has been called by com.sun.marlin.OffHeapArray (file:/C:/Users/sblantipodi/.m2/repository/org/openjfx/javafx-graphics/24/javafx-graphics-24-win.jar) WARNING: Please consider reporting this to the maintainers of class com.sun.marlin.OffHeapArray WARNING: sun.misc.Unsafe::allocateMemory will be removed in a future release Reporting them :) From kevin.rushforth at oracle.com Tue Jul 29 13:50:09 2025 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 29 Jul 2025 06:50:09 -0700 Subject: JDK24 WARNING: Please consider reporting this to the maintainers of class com.sun.marlin.OffHeapArray In-Reply-To: <26111975-94af-44bc-8749-327972b0efbe@dpsoftware.org> References: <26111975-94af-44bc-8749-327972b0efbe@dpsoftware.org> Message-ID: <16293249-7d78-48b3-8498-8a9d4062b736@oracle.com> Thanks for the report. This has been fixed in JavaFX 25 by JDK-8334137 [1]. Thanks. -- Kevin [1] https://bugs.openjdk.org/browse/JDK-8334137 On 7/29/2025 6:06 AM, Davide Perini wrote: > Using JDK 24.0.2 and JavaFX 24 I get a lot of warnings: > > WARNING: A terminally deprecated method in sun.misc.Unsafe has been > called > WARNING: sun.misc.Unsafe::allocateMemory has been called by > com.sun.marlin.OffHeapArray > (file:/C:/Users/sblantipodi/.m2/repository/org/openjfx/javafx-graphics/24/javafx-graphics-24-win.jar) > WARNING: Please consider reporting this to the maintainers of class > com.sun.marlin.OffHeapArray > WARNING: sun.misc.Unsafe::allocateMemory will be removed in a future > release > > Reporting them :)