On Wed, 7 May 2025 13:26:01 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:

>>> I think it (creating things in a background thread) was a mistake in the 
>>> first place, but there seems to be zero desire to change it
>> 
>> Your objection is noted, but we are not going to relitigate this. JavaFX 
>> explicitly allows creation and modification of a scene graph on a thread 
>> other than the JavaFX application thread up to the point before that scene 
>> is attached to a window.
>> 
>> This means that we do need to be careful in our implementation, especially 
>> avoiding anything that might run on the application thread prior to the 
>> scene becoming "live". Sometimes that means deferring the adding of 
>> listeners as was recently done for charts. It sounds like that's what is 
>> being done here by deferring the subscription to platform preferences until 
>> the scene is shown.
>
> @kevinrushforth ... what about manipulating a Scene that was at some point 
> attached to a Window?  I mean, I've built a solution specifically for 
> just-in-time registration **and** unregistration of listeners.  So IMHO when 
> a Scene is detached or the window is no longer showing (basically any time it 
> doesn't have a peer) then listeners need to detach as well (and re-attach 
> when that situation changes again).

The Scene specification says "A Scene may be created and modified on any thread 
until it is attached to a Window that is showing. After that, it must be 
modified only on the JavaFX Application Thread."

So that doesn't allow for "transferring it" back to a background thread when 
you remove it. If we wanted to relax that, it would take additional work for 
nodes that use animation or setup other listeners that fire on the JavaFX 
application thread.

The use case for doing so seems pretty narrow, and I'm not sure it is worth it.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077760589

Reply via email to