On Thu, 15 May 2025 17:50:50 GMT, Michael Strauß <mstra...@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
