Looks good to me.
On 8/30/16 7:18 PM, Semyon Sadetsky wrote:
Sorry for inconvenience, but I have to update this fix once again.
http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.02
I have found the main root cause of the issue. In the 8036815 I have
missed one insets_corrected = true; statement in the RaparentNotify
handler. In my new Unity algo for establishing frame dimensions the
insets correction should be postponed until the frame extent property
is set. This is corrected in the updated fix.
Also the frame insets correction optimization is restored with only
one exclusion when the client area is not set to ensure that the
target frame will receive the final size and location update.
--Semyon
On 8/24/2016 4:24 PM, Semyon Sadetsky wrote:
The fix was amended to
http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.01/
Because Unity WM may change initial window location (for example when
window overlaps desktop bars) I removed the optimization that skipped
frame bounds revalidation in case of the initial frame insets was
correct. This should guaranty the ConfigureNotify event always to
come after the extent size event.
--Semyon
On 8/22/2016 9:19 PM, Semyon Sadetsky wrote:
Hello,
Please review fix for JDK9:
bug: https://bugs.openjdk.java.net/browse/JDK-8161910
webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/
A regression of the 8036915 in which a new frame dimensioning algo
was introduced for the Unity WM because the latter differs from
other WMs a lot. The algo has a flaw in some scenarios when the
extent size event is delayed while the initial frame insets were
established correctly, therefore the frame dimensions do not require
any tuning. In this case the content window need to be notified
right in the extent event handler to let the content to receive its
new dimensions because subsequent XConfigureNotify event may be
omitted.
--Semyon
--
Thanks,
Alexander.
