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