I noticed the copy/paste I did wasn't great, you don't need the `future`
variable or code that manipulates it (I had a different version before,
but this works quite well for now)
--John
On 08/08/2024 12:47, Thiago Milczarek Sayão wrote:
Nice! I will steal it if you don't mind.
Em qua., 7 de
Feel free, it is also somewhere on my github. I'm not entirely
confident it works for all cases, but it can be tweaked. Here's the
missing piece you may need:
/**
* Tracks time spent (in milliseconds) between calls of {@link
#enterNested()}and {@link #exitNested()}
* excluding time spent i
One should probably use System.nanoTime() instead of .currentTimeMillis() ...
-andy
From: openjfx-dev on behalf of Thiago Milczarek
Sayão
Date: Thursday, August 8, 2024 at 03:47
To: John Hendrikx
Cc: openjfx-dev@openjdk.org
Subject: Re: Detecting threading problems faster
Nice! I will steal
Nice! I will steal it if you don't mind.
Em qua., 7 de ago. de 2024 às 15:55, John Hendrikx
escreveu:
> For detecting long running tasks on the FX thread, there are some other
> options which you can do as a user (but perhaps we can support it directly
> within FX). I use this kind of code to d
24 at 14:53
To: Andy Goryachev , openjfx-dev@openjdk.org
Subject: Re: [External] : Re: Detecting threading problems faster
On 07/08/2024 21:38, Andy Goryachev wrote:
John:
Looks like the issue in PR#1123 was caused by application code accessing FX
from a non-FX thread.
That does seem likely, but it i
n Hendrikx
*Date: *Wednesday, August 7, 2024 at 12:01
*To: *Andy Goryachev ,
openjfx-dev@openjdk.org
*Subject: *[External] : Re: Detecting threading problems faster
Hi Andy,
Problems that occur due to modifying the scene graph (like
adding/removing children, or changing certain properties)
m the FX application thread.
I am curious what other members of community think of this issue.
-andy
From: John Hendrikx
Date: Wednesday, August 7, 2024 at 12:01
To: Andy Goryachev , openjfx-dev@openjdk.org
Subject: [External] : Re: Detecting threading problems faster
Hi Andy,
Problems
, August 4, 2024 at 16:30
*To: *openjfx-dev@openjdk.org
*Subject: *Detecting threading problems faster
Hi list,
I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX. Basically, anything directly or
indirectly linked to an active Scene must be accessed
For detecting long running tasks on the FX thread, there are some other
options which you can do as a user (but perhaps we can support it
directly within FX). I use this kind of code to detect long running
things on the FX thread:
/**
* Adds a slow event warning whenever an event takes more
Hey Michael,
Thanks, I totally forgotten about that post apparently, perhaps we can
make this work.
I thought of something else as well. We seem to be assuming that
checking the Thread is the expensive part, where it in reality is one of
the cheapest checks that we can do. We could always c
rom: *openjfx-dev on behalf of John
> Hendrikx
> *Date: *Sunday, August 4, 2024 at 16:30
> *To: *openjfx-dev@openjdk.org
> *Subject: *Detecting threading problems faster
>
> Hi list,
>
> I know of quite some bugs and users that have been bitten by the
> threading model
Hi John,
this seems to be a very similar idea to what I've proposed a year ago:
https://mail.openjdk.org/pipermail/openjfx-dev/2023-August/041925.html
I think the potential performance impact needs to be carefully considered.
Hi,
Interesting idea. We have this problem specially when Junior developers
touch the code.
The other way around would be nice too - if some I/O task executes on the
FX thread.
This can make the OS think the application hanged and offer to kill it,
since it won't respond to "pings". And I/O task
, August 4, 2024 at 16:30
To: openjfx-dev@openjdk.org
Subject: Detecting threading problems faster
Hi list,
I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX. Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX
Wouldn't it be better to implement this check in assert to avoid any
impact in production?
No. Using an assert in a case like this is an anti-pattern. A call to
assert in a library such as JavaFX is only appropriate for checking an
invariant in internal logic. If we are going to go down this r
Hello,
Wouldn't it be better to implement this check in assert to avoid any impact
in production?
пн, 5 авг. 2024 г. в 03:30, John Hendrikx :
> Hi list,
>
> I know of quite some bugs and users that have been bitten by the
> threading model used by JavaFX. Basically, anything directly or
> indir
Hi list,
I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX. Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displ
17 matches
Mail list logo
