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

[Jayathirth Rao]

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