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
> 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
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+),
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
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.
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.
>
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
>>
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.
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
>
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,
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
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,
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
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.
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
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+),
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
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:
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+),
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
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
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
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
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
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
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
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
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:
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
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
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
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
> 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
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
> 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
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
36 matches
Mail list logo