I do not know. I am not very familiar with the initialisation
dependencies here.
I pointed out the potential for such circularity problems in the bug report.
If there is an issue then the fix will need to be a lot more tricky and
maybe
Alexander needs to take a look. The alternative of just returning "width"
in the case that GetInstance returns null would seem like it would be safe
but will presumably return an incorrect answer for some configs that
will "change" in subsequent calls. Note that I can't start a PIT respin
without a fix here so it needs to be investigated and fixed with some
urgency.
-phil.
On 11/25/2015 12:19 PM, Sergey Bylokhov wrote:
Hi, Phil.
Is it possible that the code in the Devices::UpdateInstance assume
that some other initialization should be done before? For example the
initializations steps in the Win32GraphicsEnvironment.java:
// Ensure awt is loaded already. Also, this forces static init
// of WToolkit and Toolkit, which we depend upon
WToolkit.loadLibraries();
// setup flags before initializing native layer
WindowsFlags.initFlags();
initDisplayWrapper();
->>>> then in native
// This method needs to be called prior to any display-related
activity
SetProcessDPIAwareProperty();
DWMIsCompositionEnabled();
initScreens(env);
->>>>
!Devices::UpdateInstance(env)
It seems that in your fix device will be initialized before
initFlags()/SetProcessDPIAwareProperty/DWMIsCompositionEnabled, right?
On 25.11.15 22:39, Phil Race wrote:
This resolves a crash on WIndows startup due to changes in the hidpi
support
that requires the graphics devices be initialised first in order to get
screen dimensions.
http://cr.openjdk.java.net/~prr/8144074/
https://bugs.openjdk.java.net/browse/JDK-8144074
-phil.
