[OpenJDK 2D-Dev] RFR: 8229800 : WindowsServerCore 1809 does not provide d2d1.dll library required by awt.dll

[Alexey Ivanov]

Looks good to me too.

Regards,
Alexey

On 28/08/2019 03:56, Sergey Bylokhov wrote:
> +1
>
> On 8/27/19 10:34 am, Jayathirth Rao wrote:
>> Hi Phil,
>>
>> I went through the changes and I see that we are doing similar 
>> dynamic loading of d2d1.dll as we are doing for shcore.dll and 
>> loading code looks good.
>> Also I confirmed that among the overloaded functions of 
>> D2D1CreateFactory, the one with 4 arguments is the generic one.
>>
>> I have not verified build and logic by importing the code, but 
>> overall change looks good to me.
>>
>> Thanks,
>> Jay
>>
>>> On 27-Aug-2019, at 9:27 PM, Phil Race <philip.race at oracle.com> wrote:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8229800
>>> webrev : http://cr.openjdk.java.net/~prr/8229800/
>>>
>>> Since JDK 9, awt.dll has linked against d2d1.dll - a Direct2D 
>>> library - in order to
>>> call a method to get the screen dpi on Windows 7 and earlier.
>>>
>>> It appears that Windows Core Server used to include this library but 
>>> recent
>>> versions do not.
>>>
>>> As a result an app that loads AWT - even in headless mode - is DOA with
>>> an unsatisfied link on start up and no work around is possible.
>>>
>>> Windows Core Server is meant to be used for server applications and
>>> the use case here is just that but the hard compile time dependency
>>> on d2d1.dll means that even if this code isn't reached, used, or needed
>>> the app is still DOA.
>>>
>>> There may be other ways to get the screen DPI on Windows - I don't know
>>> why the hidpi support chose this approach - but the safest change 
>>> appears
>>> to be to dynamically locate this library at run time.
>>>
>>> The callers of the internal GetScreenDpi function are already prepared
>>> for it to "fail" and fall back to a default of 96 DPI.
>>>
>>> I have implemented this approach and verified it on Window 7 - which
>>> is where it is needed. A regression test is difficult since setting 
>>> values
>>> like -Dsun.java2d.uiScale mean we over-ride and don't request this
>>> setting and 96 dpi is the fallback so you could only test this as part
>>> of overall true hidpi testing. And the focus of this bug - the absence
>>> of a hard link against d2d1.dll and whether overall headless works
>>> is best tested by running any headless app on Windows Core Server.
>>>
>>> One wrinkle in the code is that the lookup of the function name
>>> needs to use the "C" binding so the signature is adjusted to match 
>>> that.
>>>
>>> The bug is marked tck-red because of the DOA, but the proposal
>>> is to just document that for JDK 13 GA this configuration isn't 
>>> supported
>>> and get the fix first into JDK 14 and then backport to 13.0.1 which 
>>> gives
>>> us a bit more time to verify the fix. It seems unlikely that this 
>>> configuration
>>> is critical for immediate adoption of 13 since it has taken 11 
>>> months for
>>> this issue to be reported.
>>>
>>> -phil.