On Thu, 15 May 2025 18:11:17 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> Some platform preference changes can trigger the emission of multiple
>> notifications. For example, when switching from a high-contrast theme on
>> Windows to the regular theme, the following notifications are emitted (log
>> can be viewed in `PlatformPreferencesChangedTest`):
>>
>>
>> changed:
>> Windows.UIColor.Accent=0x0078d4ff
>> Windows.SysColor.COLOR_HIGHLIGHTTEXT=0xffffffff
>> Windows.SysColor.COLOR_WINDOW=0xffffffff
>> Windows.UIColor.AccentLight1=0x0091f8ff
>> Windows.SysColor.COLOR_3DFACE=0xf0f0f0ff
>> Windows.SysColor.COLOR_HOTLIGHT=0x0066ccff
>> Windows.SysColor.COLOR_WINDOWTEXT=0x000000ff
>> Windows.SysColor.COLOR_BTNTEXT=0x000000ff
>> Windows.UIColor.Foreground=0x000000ff
>> Windows.UIColor.AccentDark1=0x0067c0ff
>> Windows.UIColor.Background=0xffffffff
>> Windows.UIColor.AccentLight3=0x99ebffff
>> Windows.UIColor.AccentLight2=0x4cc2ffff
>> Windows.SysColor.COLOR_GRAYTEXT=0x6d6d6dff
>> Windows.SysColor.COLOR_HIGHLIGHT=0x0078d7ff
>> Windows.UIColor.AccentDark2=0x003e92ff
>> Windows.UIColor.AccentDark3=0x001a68ff
>>
>> changed:
>> -Windows.SPI.HighContrastColorScheme
>> Windows.SPI.HighContrast=false
>>
>> changed:
>> Windows.UIColor.Foreground=0xffffffff
>> Windows.UIColor.Background=0x000000ff
>>
>>
>> Notably, the values for Windows.UIColor.Foreground/Background are
>> inconsistent between the notifications (although they are eventually
>> correct). In general, only a single notification should be emitted that
>> includes all of the changed preferences.
>>
>> This artifact is only visible on Windows. The reason is that changing some
>> system settings (like high-contrast theme) causes a number of different
>> window messages to be sent to the application. We should wait for all window
>> messages to come in, and then aggregate all of the changed preferences into
>> a single notification.
>>
>> In order to minimize the delay between changing a system setting and sending
>> out the notification in JavaFX, the implementation only waits when
>> instructed to do so by the native toolkit. This allows us to instantly send
>> out notifications for most changes, but selectively wait a bit for changes
>> where the native toolkit knows that more changes might be coming in.
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/Application.java line
> 87:
>
>> 85: public void handleQuitAction(Application app, long time) {
>> 86: }
>> 87: public void handlePreferencesChanged(Map<String, Object>
>> preferences, int suggestedDelayMillis) {
>
> I wonder if we should always debounce the changes with a short delay?
> A delay of 100-150 ms will be acceptable from the user perspective.
> What do you think?
Most changed settings are not correlated with other settings, so no waiting is
necessary (for example, we wouldn't wait after a `reducedMotion` change). We
only need to wait a bit when a single user-facing setting can affect several
correlated preferences. This only seems to be the case on Windows, and only
when changing high-contrast themes.
-------------
PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091760658
