On Thu, 14 Oct 2021 17:14:11 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8273485
>> Added check for null when calling initScreens
>
> mod
On Mon, 23 May 2022 20:44:47 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in th
On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote:
>> @johanvos
>> As requested, we've made a unit test, which tests this bug.
>> It's based on your test and our original test class. It can be added to the
>> ListViewTest.
>> You can find it, in the JDK ticket.
>>
>> Btw, adding the cells incre
On Sun, 8 May 2022 18:56:45 GMT, Johan Vos wrote:
>> @johanvos
>> As requested, we've made a unit test, which tests this bug.
>> It's based on your test and our original test class. It can be added to the
>> ListViewTest.
>> You can find it, in the JDK ticket.
>>
>> Btw, adding the cells incre
On Thu, 14 Apr 2022 08:52:27 GMT, Johan Vos wrote:
>> Johan Vos has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Don't shift cells if we are already showing the lowest index cell.
>
> I agree with that observation. The mathematical perfec
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in th
On Wed, 30 Mar 2022 13:27:40 GMT, Johan Vos wrote:
>> When the size of a ListCell is changed and a scrollTo method is invoked
>> without having a layout calculation in between, the old (wrong) size is used
>> to calculcate the total estimate. This happens e.g. when the size is changed
>> in th
On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier
wrote:
> Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or
> mouseDown is true, the sbTouch animation is running,
> and the node is removed from the Scene, then the animation will never stop,
> caus
"reshown", but it
> restores sanity about memory behaviour, which should be considered more
> important.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8269907
Removed the sync methods for the scene, bec
On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote:
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `up
On Wed, 5 Jan 2022 18:14:44 GMT, Florian Kirmaier wrote:
>> Making the initial listener of the ListProperty weak fixes the problem.
>> The same is fixed for Set and Map.
>> Due to a smart implementation, this is done without any performance drawback.
>> (The trick is to
)
> By implying the same trick to the InvalidationListener, this should even
> improve the performance of the collection properties.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8277848
Added the 3
On Mon, 10 Jan 2022 12:29:04 GMT, Florian Kirmaier
wrote:
>> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added
>> a unit-test for it.
>> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397
>> run test: `./gradlew --continue -PFULL_TEST=tr
> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added
> a unit-test for it.
> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397
> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests
> "*MultipleSelectionModelImplTest*&quo
> Fixing IndexOutOfBoundsException in the MultipleSelectionModelBase and added
> a unit-test for it.
> ticket: https://bugs.openjdk.java.net/browse/JDK-8256397
> run test: `./gradlew --continue -PFULL_TEST=true controls:test --tests
> "*MultipleSelectionModelImplTest*&quo
On Sun, 9 Jan 2022 15:20:36 GMT, Johan Vos wrote:
> When the size of a ListCell is changed and a scrollTo method is invoked
> without having a layout calculation in between, the old (wrong) size is used
> to calculcate the total estimate. This happens e.g. when the size is changed
> in the `up
On Thu, 23 Dec 2021 17:43:19 GMT, Florian Kirmaier
wrote:
> Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or
> mouseDown is true, the sbTouch animation is running,
> and the node is removed from the Scene, then the animation will never stop,
> caus
On Fri, 31 Dec 2021 12:53:54 GMT, Michael Strauß wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8277848
>> Added missing change
>
> Why are the new listener imlem
)
> By implying the same trick to the InvalidationListener, this should even
> improve the performance of the collection properties.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8277848
Further optimization base
Fixing memoryleak, related to touch events in ScrollPaneWhen touchDetected or
mouseDown is true, the sbTouch animation is running,
and the node is removed from the Scene, then the animation will never stop,
causing a memory leak.
A simple fix is to also check, whether the Node is visible, by che
On Thu, 16 Dec 2021 14:29:21 GMT, Florian Kirmaier
wrote:
> Fixing typo in EnumConverter
This pull request has now been integrated.
Changeset: 4c5bf44e
Author: Florian Kirmaier
Committer: Kevin Rushforth
URL:
https://git.openjdk.java.net/jfx/com
Fixing typo in EnumConverter
-
Commit messages:
- 8278905
Changes: https://git.openjdk.java.net/jfx/pull/697/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=697&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8278905
Stats: 1 line in 1 file changed: 0 ins;
)
> By implying the same trick to the InvalidationListener, this should even
> improve the performance of the collection properties.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8277848
Added missing change
On Thu, 9 Dec 2021 12:45:32 GMT, Florian Kirmaier wrote:
>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the
>> dirtyNodes are unset, the whole scene is basically considered
"reshown", but it
> restores sanity about memory behaviour, which should be considered more
> important.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8269907
Fixed rare bug, causing bounds to be out of syn
Making the initial listener of the ListProperty weak fixes the problem.
The same is fixed for Set and Map.
Due to a smart implementation, this is done without any performance drawback.
(The trick is to have an object, which is both the WeakReference and the
Changelistener)
By implying the same tri
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote:
> Create sources.jars and attach they to the publish task, so that they can be
> uploaded to the (e.g. maven) repository automatically.
I wonder how the sources for the official maven release are generated?
https://repo1.maven.org/maven2/org/o
On Sat, 30 Oct 2021 10:56:40 GMT, Florian Kirmaier
wrote:
> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17.
> To fix it, I've made the Value of the WeakHashMap also weak.
> We only keep this value to remove it as a listener later on. Therefore there
On Mon, 15 Nov 2021 08:24:04 GMT, Florian Kirmaier
wrote:
>> This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17.
>> To fix it, I've made the Value of the WeakHashMap also weak.
>> We only keep this value to remove it as a listener later on. Theref
On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
Added check for null when calling initScreen
On Fri, 12 Nov 2021 23:42:30 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274022
>> Simplified code related to WeakHashMaps
>
> modules/javafx.c
t's especially annoying
> because it takes some time until the application gets unstable.
>
> Therefore **I would recommend** after this fix is approved, **to make a new
> version for JavaFX17** with this fix because this bug is so severe.
Florian Kirmaier has updated the pull req
t's especially annoying
> because it takes some time until the application gets unstable.
>
> Therefore **I would recommend** after this fix is approved, **to make a new
> version for JavaFX17** with this fix because this bug is so severe.
Florian Kirmaier has updated the pull req
On Fri, 12 Nov 2021 22:42:35 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274022
>> Simplified code related to WeakHashMaps
>
> modules/javafx.c
On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier
wrote:
> removing dead code.
> When looking into the font code, I've noticed that this code is no longer
> used, so I thought I should make a PR with a minor cleanup.
This pull request has now been integrated.
Changeset: c
On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
On Sat, 30 Oct 2021 13:35:39 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8273485
>> Fixing toggle fullscreen!
>
> modules/javaf
On Tue, 2 Nov 2021 10:15:41 GMT, Florian Kirmaier wrote:
>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the
>> dirtyNodes are unset, the whole scene is basically considered
"reshown", but it
> restores sanity about memory behaviour, which should be considered more
> important.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8269907
We now require the rendering lock when clea
t's especially annoying
> because it takes some time until the application gets unstable.
>
> Therefore **I would recommend** after this fix is approved, **to make a new
> version for JavaFX17** with this fix because this bug is so severe.
Florian Kirmaier has updated the pull req
On Sun, 31 Oct 2021 16:32:49 GMT, Michael Strauß wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8274022
>> Simplified code related to WeakHashMaps
>
> modules/javafx.c
t's especially annoying
> because it takes some time until the application gets unstable.
>
> Therefore **I would recommend** after this fix is approved, **to make a new
> version for JavaFX17** with this fix because this bug is so severe.
Florian Kirmaier has updated the pull req
This fixes the new ControlAcceleratorBug which was Introduced in JavaFX17.
To fix it, I've made the Value of the WeakHashMap also weak.
We only keep this value to remove it as a listener later on. Therefore there
shouldn't be issues by making this value weak.
I've seen this Bug very very often,
On Fri, 29 Oct 2021 15:10:35 GMT, Florian Kirmaier
wrote:
> removing dead code.
> When looking into the font code, I've noticed that this code is no longer
> used, so I thought I should make a PR with a minor cleanup.
I've also seen many places in the font code, which ju
On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
removing dead code.
When looking into the font code, I've noticed that this code is no longer used,
so I thought I should make a PR with a minor cleanup.
-
Commit messages:
- JDK-8276179
Changes: https://git.openjdk.java.net/jfx/pull/658/files
Webrev: https://webrevs.openjdk.java.
On Thu, 14 Oct 2021 14:29:55 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8269907
>> The bug is now fixed in a new way. Toolkit now supports re
On Mon, 18 Oct 2021 08:20:22 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
Fixing toggle fullscreen!
-
Chang
and sources be generated and added to the Maven release?
Florian Kirmaier
On Tue, 28 Sep 2021 12:07:36 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
removed the toggle fullscreen before closing
On Fri, 17 Sep 2021 12:51:53 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8273485
>> small cleanup of the changes.
>
> You can also see the
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
Fixed Beep sound when closing a fullscreen windo
On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier
wrote:
> Probably my most boring PR. ;)
> Setting the lambda to null, after it has been used, fixes the leak.
This pull request has now been integrated.
Changeset: 4b9cb210
Author:Florian Kirmaier
Committer: Kevin Rushfort
> Probably my most boring PR. ;)
> Setting the lambda to null, after it has been used, fixes the leak.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273969
Some changes based on code review
-
C
On Mon, 20 Sep 2021 12:56:39 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8273969
>> Some changes based on code review
>
> tests/sy
On Thu, 16 Sep 2021 13:22:32 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier
wrote:
> Probably my most boring PR. ;)
> Setting the lambda to null, after it has been used, fixes the leak.
I guess that makes sense - but I can think of a million ways to create nearly
unsolvable problems with it.
-
PR:
Probably my most boring PR. ;)
Setting the lambda to null, after it has been used, fixes the leak.
-
Commit messages:
- JDK-8273969
Changes: https://git.openjdk.java.net/jfx/pull/626/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=626&range=00
Issue: https://bugs.open
On Sun, 19 Sep 2021 15:33:46 GMT, Florian Kirmaier
wrote:
> Probably my most boring PR. ;)
> Setting the lambda to null, after it has been used, fixes the leak.
For the strange reason, why i haven't used a lambda for the test, I've created
another ticket: https://bugs.openjdk
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
small cleanup of the changes
On Mon, 13 Sep 2021 13:35:52 GMT, Florian Kirmaier
wrote:
>> When using Swing it's possible to generate a Deadlock.
>> It's related to the nested eventloop started in enterFullScreenExitingLoop
>> - and the RenderLock aquired when using setView in Scene.
>>
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
Removed the enter/leave ne
ng the nested loop fixes the Problem.
> I hope this doesn't have any side effect - so far i don't know of any.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8273485
Added unit-test
-
Changes:
- a
On Wed, 8 Sep 2021 10:37:40 GMT, Florian Kirmaier wrote:
> When using Swing it's possible to generate a Deadlock.
> It's related to the nested eventloop started in enterFullScreenExitingLoop -
> and the RenderLock aquired when using setView in Scene.
> Sample Programm an
When using Swing it's possible to generate a Deadlock.
It's related to the nested eventloop started in enterFullScreenExitingLoop -
and the RenderLock aquired when using setView in Scene.
Sample Programm and Threaddump are added to the ticket.
Removing the nested loop fixes the Problem.
I hope
a new one is created for the Printing Thread.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8271395
QuantumRenderer is no longer public
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/618/
On Mon, 6 Sep 2021 13:33:11 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8271395
>> QuantumRenderer is no longer public
>
> modules/javafx.grap
This PR switches the Thread to the QuantumRenderer, in the case the Disposer is
called from another Thread - the printing Thread.
I'm open for better solutions on how to fix this Issue.
Initially i thought there is also a Race Condition in the resource pool, but a
new one is created for the Print
On Thu, 22 Jul 2021 11:50:11 GMT, Florian Kirmaier
wrote:
>> After thinking about this issue for some time, I've now got a solution.
>> I know put the scene in the state it is, before is was shown, when the
>> dirtyNodes are unset, the whole scene is basically conside
"reshown", but it
> restores sanity about memory behaviour, which should be considered more
> important.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
JDK-8269907
The bug is now fixed in a new way.
On Wed, 21 Jul 2021 11:29:38 GMT, Florian Kirmaier
wrote:
> After thinking about this issue for some time, I've now got a solution.
> I know put the scene in the state it is, before is was shown, when the
> dirtyNodes are unset, the whole scene is basically considered dirty.
Hi everyone,
I've now found a possible fix for a memory leak I discovered several weeks
ago.
Can someone take a look into it?
issue: https://bugs.openjdk.java.net/browse/JDK-8269907
PR: https://github.com/openjdk/jfx/pull/584
Greetings Florian
On Tue, 6 Jul 2021 15:07:26 GMT, Florian Kirmaier wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 386:
>>
>>> 384: private GlyphList[] getRuns() {
>>> 385: if (textRuns != null) return textRuns;
>>> 386:
On Tue, 6 Jul 2021 14:58:49 GMT, Kevin Rushforth wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8269921
>> Added a copyright header
>
> modules/javafx.graphics/src/m
s without issues in TextFlow Heavy applications.
>
> Benefits:
> * Better Tooling Support For ScenicView etc.
> * Fixes complicated but reproducible crashes
> * Might fix some rare crashes, which are hard to reproduce
> * Likely improves performance - might fix some edge
It's "a bit" complicated.
In some situations, getRuns get's called because listeners on bounds are set.
This causes TextFlow to layout to compute the runs.
Afterward, the bounds of the parents get updated.
This triggers a call to compute bounds - which cascades up to the children.
When the geometr
Hi everyone,
I've developed a fix for an exception in the MultipleSelectionModel.
Can someone look into it?
https://github.com/openjdk/jfx/pull/564
Greetings Florian Kirmaier
Hi everyone,
I was hunting for some memory leaks, but I think I need some
help/feedback/thoughts on this one.
ticket: https://bugs.openjdk.java.net/browse/JDK-8269907
A unit test can be found in the ticket.
Florian Kirmaier
On Wed, 24 Mar 2021 14:58:40 GMT, Florian Kirmaier
wrote:
> Fixing ListCell editing status is true, when index changes while editing.
This pull request has now been integrated.
Changeset: 240d28ff
Author: Florian Kirmaier
Committer: Jeanette Winzenburg
URL:
ht
On Tue, 18 May 2021 10:14:11 GMT, Florian Kirmaier
wrote:
>> Fixing ListCell editing status is true, when index changes while editing.
>
> Florian Kirmaier has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - 8264127
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127
small changes based on CR
-
Changes:
- all: https://git.openjdk.java.net/
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with two additional
commits since the last revision:
- 8264127
fixed assertion text,
exception handler is now installed/uninstalled like
On Mon, 17 May 2021 08:40:44 GMT, Jeanette Winzenburg
wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8264127
>> More changes, simplifications and tests based on CR
>
> m
On Wed, 12 May 2021 08:13:32 GMT, Florian Kirmaier
wrote:
>> Fixing ListCell editing status is true, when index changes while editing.
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8264127:
On Thu, 13 May 2021 12:29:46 GMT, Jeanette Winzenburg
wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8264127:
>> we now use a try finally statement, to make sure u
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127
More changes, simplifications and tests based on CR
-
Changes:
- all: ht
On Tue, 27 Apr 2021 11:52:58 GMT, Florian Kirmaier
wrote:
>> Fixing ListCell editing status is true, when index changes while editing.
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8264127:
>
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127:
we now use a try finally statement, to make sure updateEditingIndex is re
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127:
removed accidentally commited print statements.
-
Changes:
- all: ht
On Tue, 27 Apr 2021 10:38:07 GMT, Jeanette Winzenburg
wrote:
>> I've now rewritten the code. It's now way simpler and avoids duplicate code.
>> I guess the different implementation in the different cells all have some
>> subtle differences.
>>
>> Then i guess we wait for the other review to f
On Sun, 11 Apr 2021 15:48:11 GMT, Florian Kirmaier
wrote:
>> Fixing a memory leak.
>> A node hard references its old parent after CSS layout and getting removed.
>> This shouldn't be the case, this is very counterintuitive.
>>
>> The fix uses a
On Wed, 10 Mar 2021 22:25:32 GMT, Florian Kirmaier
wrote:
> Fixing a memory leak.
> A node hard references its old parent after CSS layout and getting removed.
> This shouldn't be the case, this is very counterintuitive.
>
> The fix uses a WeakReference i
On Sat, 3 Apr 2021 15:35:19 GMT, Florian Kirmaier wrote:
> Fixing leak in ProgressIndicator when treeShowing is false
This pull request has now been integrated.
Changeset: 483f171a
Author: Florian Kirmaier
Committer: Kevin Rushforth
URL: https://git.openjdk.java.net/jfx/com
On Mon, 26 Apr 2021 11:46:57 GMT, Jeanette Winzenburg
wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8264127:
>> Added missing test case
>
> modules/javafx.control
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127:
restructured the if/else cascade in updating index. It's now simpler an less
nested a
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with two additional
commits since the last revision:
- 8264127:
Added more asserts to the ListCellTest, to make it more symmetric to the
other t
On Mon, 26 Apr 2021 11:34:34 GMT, Jeanette Winzenburg
wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8264127:
>> Added missing test case
>
> modules/javafx.controls/src
1 - 100 of 298 matches
Mail list logo
