> 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.

Michael Strauß has updated the pull request incrementally with one additional 
commit since the last revision:

  simplified DelayedChangedAggregator

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

Changes:
  - all: https://git.openjdk.org/jfx/pull/1810/files
  - new: https://git.openjdk.org/jfx/pull/1810/files/a512dc4d..8fce572c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jfx&pr=1810&range=01
 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1810&range=00-01

  Stats: 77 lines in 3 files changed: 15 ins; 25 del; 37 mod
  Patch: https://git.openjdk.org/jfx/pull/1810.diff
  Fetch: git fetch https://git.openjdk.org/jfx.git pull/1810/head:pull/1810

PR: https://git.openjdk.org/jfx/pull/1810

Reply via email to