RFR: 8357067: Platform preference change can emit multiple notifications

[Andy Goryachev]

On Thu, 15 May 2025 17:50:50 GMT, Michael Strauß <mstrauss at 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?

modules/javafx.graphics/src/main/native-glass/win/PlatformSupport.h line 75:

> 73:      * Suggested aggregation delay for changes that come in over a period of time.
> 74:      */
> 75:     static constexpr int SUGGESTED_DELAY_MILLIS = 1000;

1 second seems too long.
What is the typical range for the high contrast train of changes?

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

PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091729799
PR Review Comment: https://git.openjdk.org/jfx/pull/1810#discussion_r2091733037