On Fri, 14 Feb 2025 18:26:31 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 14 Feb 2025 18:26:31 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
> ## Root Cause
> Animation gets started in a background thread, which causes the animation
> handler to run in the FX application thread, thus creating simultaneous
> access to the control's fields (list of children in this case).
>
> ## Solution
> Postpone the animation unless running in the F
On Fri, 14 Feb 2025 18:18:59 GMT, Kevin Rushforth wrote:
> Can you merge master so this will be realized?
done.
-
PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-2659998222
On Tue, 11 Feb 2025 23:33:42 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Mon, 10 Feb 2025 22:30:32 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
> ## Root Cause
> Animation gets started in a background thread, which causes the animation
> handler to run in the FX application thread, thus creating simultaneous
> access to the control's fields (list of children in this case).
>
> ## Solution
> Postpone the animation unless running in the F
On Mon, 10 Feb 2025 22:30:32 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Mon, 10 Feb 2025 22:30:32 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
> ## Root Cause
> Animation gets started in a background thread, which causes the animation
> handler to run in the FX application thread, thus creating simultaneous
> access to the control's fields (list of children in this case).
>
> ## Solution
> Postpone the animation unless running in the F
On Fri, 7 Feb 2025 23:00:37 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Mon, 10 Feb 2025 17:03:49 GMT, Andy Goryachev wrote:
> You are probably right about `System.gc()` being called too often. I would
> say though that the purpose of this test is to uncover initialization issues
> rather than finding other problems with the controls, so it's probably ok as
> i
On Fri, 7 Feb 2025 23:00:37 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 7 Feb 2025 23:00:37 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
> ## Root Cause
> Animation gets started in a background thread, which causes the animation
> handler to run in the FX application thread, thus creating simultaneous
> access to the control's fields (list of children in this case).
>
> ## Solution
> Postpone the animation unless running in the F
On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 7 Feb 2025 21:49:24 GMT, Kevin Rushforth wrote:
> A better solution might be to set the max heap to 1Gb in the system tests
> project in `build.gradle`.
created https://bugs.openjdk.org/browse/JDK-8349679
-
PR Comment: https://git.openjdk.org/jfx/pull/1698#issuecomment-264
On Fri, 7 Feb 2025 21:38:15 GMT, Andy Goryachev wrote:
> I see the problem with gradle (I was running it in Eclipse). We apparently
> set -Xmx512m which is simply inadequate. We should at least double that, or
> even go to 2GB.
>
> Where is it being set?
The default is set by the gradle insta
On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
On Fri, 7 Feb 2025 18:41:53 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> Animation gets started in a background thread, which causes the animation
>> handler to run in the FX application thread, thus creating simultaneous
>> access to the control's fields (list of children in this case).
>>
> ## Root Cause
> Animation gets started in a background thread, which causes the animation
> handler to run in the FX application thread, thus creating simultaneous
> access to the control's fields (list of children in this case).
>
> ## Solution
> Postpone the animation unless running in the F
On Fri, 7 Feb 2025 16:01:02 GMT, Andy Goryachev wrote:
> This may be a memory leak, or it could simply be expected - after all, it is
> a stress test and we do create heavy objects in a tight loop.
>
> I think it's worth investigating in the context of this ticket. Thank you!
Yep, it does need
On Fri, 7 Feb 2025 00:42:35 GMT, Kevin Rushforth wrote:
> The test runs out of heap space for me on Windows
This may be a memory leak, or it could simply be expected - after all, it is a
stress test and we do create heavy objects in a tight loop.
I think it's worth investigating in the context
On Thu, 6 Feb 2025 20:43:54 GMT, Andy Goryachev wrote:
> ## Root Cause
> Animation gets started in a background thread, which causes the animation
> handler to run in the FX application thread, thus creating simultaneous
> access to the control's fields (list of children in this case).
>
> ##
## Root Cause
Animation gets started in a background thread, which causes the animation
handler to run in the FX application thread, thus creating simultaneous access
to the control's fields (list of children in this case).
## Solution
Postpone the animation unless running in the FX application
28 matches
Mail list logo
