Increased max heap size for system tests from 521Mb to 1000Mb.
-
Commit messages:
- increase max heap size for system tests
Changes: https://git.openjdk.org/jfx/pull/1701/files
Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1701&range=00
Issue: https://bugs.openjdk.org/browse/
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 Sat, 25 Jan 2025 07:28:32 GMT, Nir Lisker wrote:
>> A batch of typo and grammar fixes that were found by the spellchecker.
>>
>> Integration can wait until RDP 1/2.
>
> Nir Lisker has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Revert "
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).
>>
Clean merge from `jfx:jfx24`.
-
Commit messages:
- Merge remote-tracking branch 'jfx/jfx24' into
merge-jfx-jfx24-to-master-2025-02-07
- 8348895: [testbug] Skip failing 3D lighting tests on macOS 14 or later on
aarch64
- 8348744: Application window not always activated on macOS 15
On Fri, 7 Feb 2025 20:51:24 GMT, Kevin Rushforth wrote:
> Clean merge from `jfx:jfx24`.
This pull request has now been integrated.
Changeset: ec6b68c3
Author:Kevin Rushforth
URL:
https://git.openjdk.org/jfx24u/commit/ec6b68c37b44fb1fc5eba0e3b6572649ff9692ee
Stats: 249 lines in 9
> Clean merge from `jfx:jfx24`.
Kevin Rushforth has updated the pull request with a new target base due to a
merge or a rebase. The incremental webrev excludes the unrelated changes
brought in by the merge/rebase. The pull request contains three additional
commits since the last revision:
- M
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 Feb 6, 2025, at 11:52 PM, Michael Strauß wrote:
>
>> This PR uses an event dispatcher to provide a cleaner way of channeling
>> keyboard events to another node. I haven’t prototyped the code but I suspect
>> a Control could do this using the existing API without any changes to the
>> N
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 19:16:48 GMT, Andy Goryachev wrote:
>> ## Root Cause
>> navigating up the parent hierarchy during CSS processing in a background
>> thread encounters a null parent, causing the NPE. The null parent comes
>> from a static Toolkit.BEHAVIOR field.
>>
>> ## Solution
>> avoid th
> ## Root Cause
> navigating up the parent hierarchy during CSS processing in a background
> thread encounters a null parent, causing the NPE. The null parent comes from
> a static Toolkit.BEHAVIOR field.
>
> ## Solution
> avoid that code path if not in the fx application thread.
Andy Goryache
> Navigating up the parent hierarchy during CSS processing in a background
> thread encounters a null parent, causing a NPE.
Andy Goryachev has updated the pull request with a new target base due to a
merge or a rebase. The pull request now contains 18 commits:
- Merge branch 'master' into 834
> Root Cause:
> (Multiple) properties are getting bound to the global
> `Platform.accessibilityActive` property. Binding (and I say, accessing) of
> properties is not thread-safe.
>
> I also changed the design a bit. Originally, every symbol in a chart had its
> `focusTraversableProperty` boun
> ## 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
> ## 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
> Skip the animation.
>
> The fix is similar to
On Thu, 6 Feb 2025 18:35:06 GMT, Andy Goryachev wrote:
> Navigating up the parent hierarchy during CSS processing in a background
> thread encounters a null parent, causing a NPE.
I think the root cause of the problem is in `Tooltip::getStyleableParent`,
which does not return a stable result w
On Thu, 30 Jan 2025 23:35:05 GMT, Andy Goryachev wrote:
> Thread-safe and re-entrant implementation of Utils.
>
> The new code still uses the static instances of Text and TextLayout for
> performance reasons, but adds a thread-safe mechanism to keep track of
> whether any of the instances is i
On Fri, 7 Feb 2025 18:03:41 GMT, Kevin Rushforth wrote:
> Your solution is basically what I meant by option 2.
right. "only one thread" threw me off, sorry.
-
PR Comment: https://git.openjdk.org/jfx/pull/1691#issuecomment-2643660437
On Fri, 7 Feb 2025 17:55:28 GMT, Andy Goryachev wrote:
> Hmmm, to further make a point: options 2 and 3 may not be re-entrant, so they
> probably won't work.
Your solution is basically what I meant by option 2. The way you did it, always
using the return value of a method that will return a "s
On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote:
>> Thread-safe and re-entrant implementation of Utils.
>>
>> The new code still uses the static instances of Text and TextLayout for
>> performance reasons, but adds a thread-safe mechanism to keep track of
>> whether any of the instances
On Fri, 31 Jan 2025 02:37:42 GMT, Michael Strauß wrote:
> When the current editor value of a `ComboBox` is added to its items list, the
> editor value may be changed to an entirely unrelated item in the list.
> However, our expectation would be that the editor reflects the newly added
> item i
On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote:
>> Thread-safe and re-entrant implementation of Utils.
>>
>> The new code still uses the static instances of Text and TextLayout for
>> performance reasons, but adds a thread-safe mechanism to keep track of
>> whether any of the instances
On Fri, 31 Jan 2025 19:18:17 GMT, Michael Strauß wrote:
>> When the current editor value of a `ComboBox` is added to its items list,
>> the editor value may be changed to an entirely unrelated item in the list.
>> However, our expectation would be that the editor reflects the newly added
>> it
On Thu, 6 Feb 2025 23:20:30 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 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 16:33:27 GMT, Andy Goryachev wrote:
>> Thread-safe and re-entrant implementation of Utils.
>>
>> The new code still uses the static instances of Text and TextLayout for
>> performance reasons, but adds a thread-safe mechanism to keep track of
>> whether any of the instances
On Fri, 7 Feb 2025 16:33:27 GMT, Andy Goryachev wrote:
>> Thread-safe and re-entrant implementation of Utils.
>>
>> The new code still uses the static instances of Text and TextLayout for
>> performance reasons, but adds a thread-safe mechanism to keep track of
>> whether any of the instances
> Thread-safe and re-entrant implementation of Utils.
>
> The new code still uses the static instances of Text and TextLayout for
> performance reasons, but adds a thread-safe mechanism to keep track of
> whether any of the instances is in use and when that happens, supplies a new
> instance in
On Thu, 6 Feb 2025 23:39:26 GMT, Kevin Rushforth wrote:
>> Thread-safe and re-entrant implementation of Utils.
>>
>> The new code still uses the static instances of Text and TextLayout for
>> performance reasons, but adds a thread-safe mechanism to keep track of
>> whether any of the instances
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 Fri, 7 Feb 2025 07:58:47 GMT, Michael Strauß wrote:
> What's the rationale for using a borrow pattern here, instead of simply
> synchronizing access to the object in question?
A very good question!
This pattern seemed to be the most applicable here: the solution needs to be
both thread-saf
On Tue, 4 Feb 2025 19:47:34 GMT, Kevin Rushforth wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> move enum field to top
>
> modules/javafx.base/src/main/java/com/sun/javafx/PreviewFeature.java line 52:
>
>> 50:
> This PR contains a definition of preview features for JavaFX, as well as a
> helper class to verify that an application has opted into preview features.
Michael Strauß has updated the pull request incrementally with four additional
commits since the last revision:
- javadoc
- remove support
> - Make it clear which values are snapped, raw or near-snapped by using
> prefixes "raw", "snapped" and "near" in variables and method names.
> Much of the code incorrectly assumes that adding, subtracting or
> multiplying two snapped values results in a snapped value. This is not
> true, it is o
40 matches
Mail list logo
