<AWT Dev> RFR: 8144074: [PIT] Crash calling Toolkit.getScreenSize() on Windows.

[Phil Race]

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