On Thu, 28 May 2026 22:10:39 GMT, Phil Race <[email protected]> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   explanatory comment
>
> src/java.desktop/windows/native/libawt/windows/Devices.cpp line 293:
> 
>> 291:                     theInstance->GetDevice(i, FALSE);
>> 292:                 BOOL changed = (newDevice == NULL)
>> 293:                     || !AreSameMonitorInfo(
> 
> Maybe I'm not understanding the requirements, but it seems to depend on the 
> order returned by CollectMonitors to be useful.
> Surely it won't be the case that the Nth monitor is always the one removed ?
> 
> If instead the result of CollectMonitors is changed only to remove the first 
> one, and the others are the same, all these comparisons will fail because it 
> compares based on the accidental index

This change is mainly trying to fix the case when the number of screens and the 
indices stay the same, but the monitor behind an index is replaced (e.g. during 
RDP reconnect).

The old code only invalidated devices removed from the end of the array, so it 
missed same-index replacement.

Currently, we transfer the java peer only when the monitor data at the same 
index is still the same, otherwise, the old java device is invalidated and a 
new one will be created. It's a bit conservative, but it seems correct.

We do not try to keep a java Win32GraphicsDevice if the same physical monitor 
moves to another index, because the java side treats the array index as the 
screen number, and Win32GraphicsDevice also caches screen related state such as 
the screen idString/listeners/configs etc.
In other words, it would require a much more complicated fix and refactoring, 
but I prefer to keep it simple.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/31238#discussion_r3321698368

Reply via email to