RFR: 8308955: MediaPlayer/AudioClip skip data on seek/loop

2024-01-22 Thread Alexander Matveev
This is regression from JDK-8262365. JDK-8262365 introduced support for hardware pause for audio device. For some reason we will skip ~500 ms of audio data after such pause. It is not noticeable for large audio files, but for anything small like sound effects 1-3 seconds long it is noticeable

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v4]

2024-01-22 Thread Prasanta Sadhukhan
> Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke > "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]

2024-01-22 Thread Jose Pereda
On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and >> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and >> wrapped functions for GTK 3.20+ (so systems without it still run with GTK >> 3.8+),

Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

2024-01-22 Thread John Hendrikx
On 22/01/2024 17:46, Jurgen Doll wrote: I've been delving into the usage of `aborted` and `inTimePulse` as mentioned by John and gleaned the following: 1. stop makes a best effort to abort the 'animation' if it is in the process of execution. 2. `aborted` and `inTimePulse` are reset with

Re: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2]

2024-01-22 Thread Andy Goryachev
On Mon, 22 Jan 2024 22:13:42 GMT, Martin Fox wrote: > this pattern is used throughout the code base. that might be the case, but I think we should use the right pattern for the new code. single-element array is an anachronism, especially in the case of multi-threaded code as here.

Integrated: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory

2024-01-22 Thread Martin Fox
On Wed, 20 Dec 2023 17:31:57 GMT, Martin Fox wrote: > When a Stage is closed while processing an OS message the glass peer object > is deleted immediately even if it's still executing member functions. As > glass unwinds the stack and executes cleanup code it's referencing freed > memory. >

Re: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2]

2024-01-22 Thread Martin Fox
On Mon, 22 Jan 2024 21:06:01 GMT, Andy Goryachev wrote: >> Again, thread-safety isn't an issue here. Even if the OS were to invoke the >> IM methods on different threads (which is a terrifying thought) these >> adapters are created on a per-call basis so each thread would get its own >>

Re: RFR: 8322215: [win] OS events that close the stage can cause Glass to reference freed memory [v2]

2024-01-22 Thread Kevin Rushforth
On Wed, 17 Jan 2024 16:43:23 GMT, Martin Fox wrote: >> When a Stage is closed while processing an OS message the glass peer object >> is deleted immediately even if it's still executing member functions. As >> glass unwinds the stack and executes cleanup code it's referencing freed >> memory.

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Andy Goryachev
On Mon, 22 Jan 2024 20:51:53 GMT, Kevin Rushforth wrote: >> Prasanta Sadhukhan has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Use Platform.runAndWait > > tests/system/src/test/java/test/robot/javafx/embed/swing/JFXPanelHiDPITest.java >

Re: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2]

2024-01-22 Thread Andy Goryachev
On Mon, 22 Jan 2024 20:52:56 GMT, Martin Fox wrote: >> I might be wrong, but array would need to store its size (an int, 8 bytes on >> 64 bit machines) in addition to the pointers themselves, while >> AtomicReference needs just the pointer. >> Plus, its semantics is much cleaner. > > Again,

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Kevin Rushforth
On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke >> "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created

Re: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2]

2024-01-22 Thread Martin Fox
On Mon, 22 Jan 2024 15:45:25 GMT, Andy Goryachev wrote: >> Either an array or an AtomicReference is OK in this case. AtomicReference is >> thread-safe, but that's not a concern here, since using `runAndWait` ensures >> that writing to the array happens before reading it. > > I might be wrong,

Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced

2024-01-22 Thread Michael Strauß
Hi Jurgen, starting an animation on a background thread would only be safe if the object graph affected by the animation is not accessed on the background thread after calling the play() method. Any access may potentially corrupt internal state. >From what I can see in your example, you're not

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Kevin Rushforth
On Mon, 22 Jan 2024 20:26:07 GMT, Andy Goryachev wrote: > Are there any other places where we invokeLater() instead of invokeAndWait()? > And runLater() instead of runAndWait() ? Good question. There might be, but each would need to be looked into to see whether they are causing problems.

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Andy Goryachev
On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke >> "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]

2024-01-22 Thread Jose Pereda
On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and >> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and >> wrapped functions for GTK 3.20+ (so systems without it still run with GTK >> 3.8+),

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Andy Goryachev
On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke >> "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Kevin Rushforth
On Mon, 22 Jan 2024 19:23:58 GMT, Andy Goryachev wrote: > is there a reason this test is skipped on macOS? It's unrelated to this PR, but to answer your question, the test is Windows-specific by it's use of setting `glass.win.uiScale`. - PR Comment:

Re: RFR: 8320965: Scrolling on a touch enabled display fails on Wayland [v3]

2024-01-22 Thread Kevin Rushforth
On Mon, 18 Dec 2023 11:19:18 GMT, Jose Pereda wrote: >> This PR replaces the deprecated `gdk_pointer_grab` with `gdk_seat_grab`, and >> `gdk_pointer_ungrab ` with `gdk_seat_ungrab`, using runtime checks and >> wrapped functions for GTK 3.20+ (so systems without it still run with GTK >> 3.8+),

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Andy Goryachev
On Mon, 22 Jan 2024 09:56:01 GMT, Prasanta Sadhukhan wrote: >> Test fails with >> >> JFXPanelHiDPITest > testScale FAILED >> java.lang.NullPointerException: Cannot invoke >> "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null >> >> because scenePeer is not yet created

Re: My issue seems to be lost

2024-01-22 Thread PavelTurk
Thank you very much! Best regards, Pavel On 1/22/24 7:11 PM, Kevin Rushforth wrote: https://bugs.openjdk.org/browse/JDK-8324327 On 1/22/2024 8:01 AM, Kevin Rushforth wrote: I can see it in the system. It seems to be stuck, so I'll check with the folks who process incoming  bugs to see if

Re: My issue seems to be lost

2024-01-22 Thread Kevin Rushforth
https://bugs.openjdk.org/browse/JDK-8324327 On 1/22/2024 8:01 AM, Kevin Rushforth wrote: I can see it in the system. It seems to be stuck, so I'll check with the folks who process incoming  bugs to see if can be moved along. -- Kevin On 1/22/2024 2:20 AM, PavelTurk wrote: Hello all. On

Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

2024-01-22 Thread Kevin Rushforth
I would not support your proposed 4th option. It's basically a partial fix for the solution John mentioned as his third option. Of the three John mentions, I favor either 1 or 2. I don't see a compelling reason to guarantee thread-safety for Animation objects (option 3), in which case the

Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

2024-01-22 Thread Jurgen Doll
I've been delving into the usage of `aborted` and `inTimePulse` as mentioned by John and gleaned the following: 1. stop makes a best effort to abort the 'animation' if it is in the process of execution. 2. `aborted` and `inTimePulse` are reset with every pulse. As to the options that John

Re: My issue seems to be lost

2024-01-22 Thread Kevin Rushforth
I can see it in the system. It seems to be stuck, so I'll check with the folks who process incoming  bugs to see if can be moved along. -- Kevin On 1/22/2024 2:20 AM, PavelTurk wrote: Hello all. On January 10, 2024 I opened an issue with internal review ID 9076431 about bug in ColorPicker

Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

2024-01-22 Thread John Hendrikx
This seems like a reasonable use case, and perhaps this was the original intent of the "asynchronous call" documentation. The problem though is that the play/stop code does not seem to take into account being called from a different thread (there are several synchronization issues when I

Re: RFR: 8322784: JFXPanel calls InputMethodRequests on wrong thread [v2]

2024-01-22 Thread Andy Goryachev
On Sat, 20 Jan 2024 14:07:32 GMT, Kevin Rushforth wrote: >> I'm not familiar enough with AtomicReference to have an opinion on this. >> Someone else will have to weigh in on this. > > Either an array or an AtomicReference is OK in this case. AtomicReference is > thread-safe, but that's not a

RFR: 8324270: Update boot JDK to 21.0.2

2024-01-22 Thread Ambarish Rapte
JDK 21.0.2 is now released : https://jdk.java.net/21/ Did a full CI build including Webkit and executed all headful tests. - Commit messages: - boot jdk 21.0.2 Changes: https://git.openjdk.org/jfx/pull/1345/files Webrev: https://webrevs.openjdk.org/?repo=jfx=1345=00 Issue:

Re: My issue seems to be lost

2024-01-22 Thread Nir Lisker
I don't see a ColorPicker bug in JBS that was created in the last 2 weeks, which means it's still in internal triage. Kevin will have to take a look. On Mon, Jan 22, 2024 at 12:20 PM PavelTurk wrote: > Hello all. > > On January 10, 2024 I opened an issue with internal review ID 9076431 > about

HEADS-UP: Threading restriction for Animation play, pause, stop now enforced USE CASE

2024-01-22 Thread Jurgen Doll
Here's an example as requested by Nir: public class FxTimeLineTest extends Application { private BorderPane bp = new BorderPane( new Label("Loading") ); public static void main( String[] args ) { launch( FxTimeLineTest.class, args ); } @Override public void

Re: HEADS-UP: Threading restriction for Animation play, pause, stop now enforced

2024-01-22 Thread Jurgen Doll
Hi Michael It seems we are misunderstanding one another. Firstly I agree that the animation code itself must and always has run only on the FX thread. So for example in the following code: new KeyFrame( Duration.seconds(2.5), event -> { int maxMemory = ; int

My issue seems to be lost

2024-01-22 Thread PavelTurk
Hello all. On January 10, 2024 I opened an issue with internal review ID 9076431 about bug in ColorPicker and still didn't get any answer. I waited, but almost two weeks has passed. Could anyone say anything about it? Best regards, Pavel

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v3]

2024-01-22 Thread Prasanta Sadhukhan
> Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke > "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11

2024-01-22 Thread Prasanta Sadhukhan
On Mon, 22 Jan 2024 09:01:10 GMT, Prasanta Sadhukhan wrote: > Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke > "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the

Re: RFR: 8324239: JFXPanelHiDPITest fails on Windows 11 [v2]

2024-01-22 Thread Prasanta Sadhukhan
> Test fails with > > JFXPanelHiDPITest > testScale FAILED > java.lang.NullPointerException: Cannot invoke > "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null > > because scenePeer is not yet created as the test is run with invokeLater. > FIx is to make it run with

RFR: 8324239: JFXPanelHiDPITest fails on Windows 11

2024-01-22 Thread Prasanta Sadhukhan
Test fails with JFXPanelHiDPITest > testScale FAILED java.lang.NullPointerException: Cannot invoke "java.awt.image.BufferedImage.getWidth()" because "pixelsIm" is null because scenePeer is not yet created as the test is run with invokeLater. FIx is to make it run with invokeAndWait so that