On Tue, 6 May 2025 21:03:14 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> 1. That's how it is implemented. No change events before the scene is shown >> (only initial values are read). >> 2. Now this would be a direct contradiction of the specification, which >> would make the user model much harder. Suddenly the "you can create and >> modify a scene on a background thread" becomes "you can do that, but for >> this particular API, you can't". Since we're doing all of this mainly for >> application developers, the user model must be the first consideration. > > PlatformPreferences.update() seems to be called only from the fx thread, if I > read the code right. What happens when the Scene is created in a bg thread > and a listener added to its preferences, and an event is fired? Will the > statement `#1` be still valid? (I don't see any code that delays the > dispatch until after the Scene is shown). > > `#2` - all this is good, but we seem to hand the gun to user and say: here, > shoot yourself in the foot. And they do. 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, so who am I to say otherwise? `NullCoalescingPropertyBase` (used in `ScenePreferences`) is initially disconnected. It will set its initial value to the value is reads from `PlatformPreferences`, but it will not subscribe to change notifications. The reason for this is to prevent a scene that is created on a background thread from immediately receiving change notifications on the FX thread, which could not only potentially corrupt the property state (because they're not concurrently thread-safe), but also mess up the application state. When the scene is shown, `NullCoalescingPropertyBase` will subscribe to change notifications from `PlatformPreferences`, because now we're safely on the FX thread. The code for that is in ScenePreferences:L142. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1655#discussion_r2077196617
