+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.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.
--
Best regards, Sergey.
