On Tue, 14 Jun 2022 08:42:11 GMT, Sergey Bylokhov wrote:
> That was the whole purpose of the initial 8182043 issue, to provide a
> HiDPI(or various DPI) icons for the user. If the user asks for the 16x16 we
> will provide them the MRI where the base image is 16x16, but that MRI could
> also pr
On Tue, 14 Jun 2022 06:18:50 GMT, Alexander Zuev wrote:
>> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1407:
>>
>>> 1405: int extraPaddedBorderInsets = info.dwMajorVersion >= 6 ?
>>> 1406: ::GetSystemMetrics(SM_CXPADDEDBORDER) : 0;
>>> 1407:
>>
>> The OS version
On Mon, 13 Jun 2022 21:24:09 GMT, Harshitha Onkar wrote:
>> Due to incorrect AWT Frame inset values being returned from native code, few
>> of the components in the frame were not being shown completely on Windows.
>> With the proposed fix, correct insets are obtained which in turn sizes and
>
On Mon, 13 Jun 2022 21:16:05 GMT, Alexey Ivanov wrote:
>> Harshitha Onkar has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> minor changes
>
> Marked as reviewed by aivanov (Reviewer).
> @aivanov-jdk The change author (@honkar-jdk) must is
On Thu, 9 Jun 2022 11:37:21 GMT, Matthias Baesken wrote:
> We still handle at a number of places ancient historic _MSC_VER versions of
> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
> This should be cleaned up, as long as it is not 3rd party code that we don't
> want to ad
On Mon, 13 Jun 2022 21:24:09 GMT, Harshitha Onkar wrote:
>> Due to incorrect AWT Frame inset values being returned from native code, few
>> of the components in the frame were not being shown completely on Windows.
>> With the proposed fix, correct insets are obtained which in turn sizes and
>
On Fri, 10 Jun 2022 12:22:45 GMT, Alexey Ivanov wrote:
> How would you implement this?
> I mean the user requests the icon in user's space (right?). On a High DPI
> system which may change in runtime, a larger icon version is required for
> rendering. To get a larger icon from native, we have t
On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't
>> want
On Mon, 13 Jun 2022 11:46:52 GMT, Matthias Baesken wrote:
>> We still handle at a number of places ancient historic _MSC_VER versions of
>> Visual Studio releases e.g. pre VS2013 (VS2013 has _MSC_VER 1800).
>> This should be cleaned up, as long as it is not 3rd party code that we don't
>> want