On Thu, 26 Mar 2020 11:37:06 GMT, Jeanette Winzenburg
wrote:
>
> Not included would be memory leaks introduced by whacky listening of
> ChoiceBoxSkin and TabPaneSkin to properties of the
> selectionModel. The former will (most probably) be fixed as a side-effect of
>
That’s possible. I think that’s in the ballpark, at least.
If we could somehow set the cell state before it gets added back into the
scenegraph, then the cell would be rendered correctly from the start, rather
than having its state updated halfway through the layout. I haven’t had time to
On Thu, 26 Mar 2020 19:50:05 GMT, Kevin Rushforth wrote:
>> @arapte can you also review this?
>
> @tiainen can you also take a look?
Looks ok to me. All our jenkins jobs ran successfully using JDK 14.
-
PR: https://git.openjdk.java.net/jfx/pull/152
On Thu, 26 Mar 2020 18:47:58 GMT, Kevin Rushforth wrote:
>> Now that we have switched to using gradle 6.3 we can switch to using JDK 14
>> as the boot JDK for JavaFX 15 builds.
>>
>> This will not change the minimum JDK version needed to build or run JavaFX,
>> which remains at 11. We will
Now that we have switched to using gradle 6.3 we can switch to using JDK 14 as
the boot JDK for JavaFX 15 builds.
This will not change the minimum JDK version needed to build or run JavaFX,
which remains at 11. We will continue to
generate class files using `-source 11 -target 11`.
On Thu, 26 Mar 2020 18:46:15 GMT, Kevin Rushforth wrote:
> Now that we have switched to using gradle 6.3 we can switch to using JDK 14
> as the boot JDK for JavaFX 15 builds.
>
> This will not change the minimum JDK version needed to build or run JavaFX,
> which remains at 11. We will
On Thu, 26 Mar 2020 06:25:55 GMT, Ajit Ghaisas wrote:
>> **Bug :**
>> https://bugs.openjdk.java.net/browse/JDK-8089828
>>
>> **Root Cause :**
>> RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position
>> calculation.
>>
>> **Fix :**
>> Corrected code to consider
good points, going into thinking :)
Maybe we can come up with a pattern (and its anti-pattern) about how
to use them correctly, now that we are looking more closely (and are
in the process of learning - me at least :) If we could collect the
does and donts somewhere, it would be easier
Zitat von Nir Lisker :
BTW, Tomas Mikula wrote about this on
http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html
.
There is a comment at the end that is worth a read too.
thanks for the reference, thought I had seen something like that but
couldn't find it
switching skins definitely is a valid use-case, and not that rare :)
There's an umbrella issue to look into all skins that might (or not)
leave a memory leak around after dispose:
https://bugs.openjdk.java.net/browse/JDK-8241364
-- Jeanette
Zitat von Pedro Duque Vieira :
Hi guys,
Not sure if this is the cause of some of this but...
I see some similar flags like needsRecreateCells and needsRebuildCells.
In one context (around line 1025) I see a recreateOrRebuild flag based on the
two.
Is it possible something similar is needed around here to only do something
once if
On Thu, 26 Mar 2020 08:25:11 GMT, Johan Vos wrote:
>> There is a hardcoded limit to refresh the glass view on iOS at a half rate
>> of the native refresh rate.
>>
>> This PR removes that limit.
>>
>> Since the default value for `frameInterval ` is 1 (which implies refreshing
>> at the same
On Thu, 26 Mar 2020 11:37:06 GMT, Jeanette Winzenburg
wrote:
>> @arapte @aghaisas - Can you both review this?
>
> I would like to widen the issue (and change this pull request accordingly) to
> include memory leaks of introduced
> selection- and focusModels in other controls that are caused by
On Thu, 26 Mar 2020 12:25:14 GMT, Kevin Rushforth wrote:
>> I would like to widen the issue (and change this pull request accordingly)
>> to include memory leaks of introduced
>> selection- and focusModels in other controls that are caused by the
>> basically same reason, that is strong
Yes, that's another good point about weak listeners, although in
practice it might not be much of a problem unless the listener is doing
something that is no longer valid (or computationally expensive, but
that is less likely).
Another problem is that using weak listeners can let you avoid
On Wed, 25 Mar 2020 21:20:37 GMT, Kevin Rushforth wrote:
> This upgrades the version of gradle used to build JavaFX to 6.3. The minimum
> version of gradle is not changed by the
> proposed fix, and remains at 5.3.
> I have run done a full build and test with gradle 6.3 on all three platforms.
BTW, Tomas Mikula wrote about this on
http://tomasmikula.github.io/blog/2015/02/10/the-trouble-with-weak-listeners.html
.
There is a comment at the end that is worth a read too.
On Thu, Mar 26, 2020 at 1:53 PM Jeanette Winzenburg
wrote:
>
> Zitat von Kevin Rushforth :
>
> Thanks for your
Zitat von Kevin Rushforth :
Thanks for your input!
Glad we didn't miss the "minimum bar" height - with the java doc being
really clear on that :)
What I still don't quite get is the concern about "too early" and "not
cleaning up" - maybe I misunderstand the point entirely
As for
Vote: YES
-Original Message-
From: Kevin Rushforth
Sent: Thursday, March 26, 2020 5:16 PM
To: openjfx-dev@openjdk.java.net
Subject: Re: CFV: New OpenJFX Committer: Arun Joseph
Vote: YES
On 3/26/2020 4:44 AM, Kevin Rushforth wrote:
> I hereby nominate Arun Joseph [1] to OpenJFX
Vote: YES
On Thu, Mar 26, 2020 at 1:46 PM Kevin Rushforth
wrote:
> Vote: YES
>
> On 3/26/2020 4:44 AM, Kevin Rushforth wrote:
> > I hereby nominate Arun Joseph [1] to OpenJFX Committer.
>
>
I hereby nominate Arun Joseph [1] to OpenJFX Committer.
Arun is a member of JavaFX team at Oracle, who has contributed 13
commits [2][3] to OpenJFX.
Votes are due by April 9, 2020.
Only current OpenJFX Committers [4] are eligible to vote on this
nomination. Votes must be cast in the open by
Vote: YES
On 3/26/2020 4:44 AM, Kevin Rushforth wrote:
I hereby nominate Arun Joseph [1] to OpenJFX Committer.
On Mon, 23 Mar 2020 23:45:55 GMT, Kevin Rushforth wrote:
>> I have basically the same comment / question as I asked in #147
>>
>> In general, there are two approaches to avoiding listener-related memory
>> leaks. One is to use a WeakListener; the other
>> is to explicitly remove the listener
On Thu, 26 Mar 2020 06:25:55 GMT, Ajit Ghaisas wrote:
>> **Bug :**
>> https://bugs.openjdk.java.net/browse/JDK-8089828
>>
>> **Root Cause :**
>> RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position
>> calculation.
>>
>> **Fix :**
>> Corrected code to consider
On Thu, 26 Mar 2020 08:33:29 GMT, Johan Vos wrote:
>> Like this?
>>
>> I think all C builds are covered. Gstreamer seems to have a Makefile with
>> the flags. Not sure about libxml and libxlst
>> inside javafx.web.
>
> I think it's better to split the flags between CFLAGS and CPPFLAGS (as is
On Wed, 25 Mar 2020 18:12:41 GMT, Arun Joseph wrote:
>> This bug can be reproduced when the screen resolution is at 125%, 150% and
>> 175% for Windows, which correpsonds to
>> `pixelScale` values of 1.25, 1.5 and 1.75, respectively.
>> Issue: The rectangle inside canvas is rendered on
On Wed, 25 Mar 2020 21:20:37 GMT, Kevin Rushforth wrote:
> This upgrades the version of gradle used to build JavaFX to 6.3. The minimum
> version of gradle is not changed by the
> proposed fix, and remains at 5.3.
> I have run done a full build and test with gradle 6.3 on all three platforms.
On Wed, 25 Mar 2020 00:40:01 GMT, Thiago Milczarek Sayao
wrote:
>> The problem is that gcc, for whatever reason, started issuing a (useless)
>> warning if you pass the
>> `-Werror=implicit-function-declaration` option to gcc for C++ files. I don't
>> like the solution of removing that flag
>>
On Sun, 1 Mar 2020 18:15:07 GMT, Jose Pereda wrote:
> There is a hardcoded limit to refresh the glass view on iOS at a half rate of
> the native refresh rate.
>
> This PR removes that limit.
>
> Since the default value for `frameInterval ` is 1 (which implies refreshing
> at the same rate as
> **Bug :**
> https://bugs.openjdk.java.net/browse/JDK-8089828
>
> **Root Cause :**
> RIGHT_TO_LEFT NodeOrientation was not considered during mnemonic position
> calculation.
>
> **Fix :**
> Corrected code to consider RIGHT_TO_LEFT NodeOrientation while calculating
> mnemonic position.
>
>
32 matches
Mail list logo
