<AWT Dev> [9] RFR: 6477756: GraphicsDevice.getConfigurations() is slow taking 3 or more seconds

Vadim Pakhnushev vadim.pakhnushev at oracle.com
Tue May 17 18:44:11 UTC 2016


Yeah, I've toyed with the idea of making the private field in the 
Win32GraphicsDevice but it seems overkill compared to just one (probably 
extra) module loaded...

Vadim

On 17.05.2016 21:35, Phil Race wrote:
> +1 again.
>
> I suppose we keep around the HMODULE for the life of the VM
> but it seems to be that or performance.
>
> -phil.
>
> On 05/17/2016 11:29 AM, Vadim Pakhnushev wrote:
>> On 17.05.2016 21:24, Vadim Pakhnushev wrote:
>>> On 17.05.2016 21:07, Vadim Pakhnushev wrote:
>>>> On 17.05.2016 19:01, Sergey Bylokhov wrote:
>>>>> On 17.05.16 18:54, Vadim Pakhnushev wrote:
>>>>>> For me this bug reproduces only when running through the RDP and 
>>>>>> with
>>>>>> -Dsun.java2d.d3d=false flag.
>>>>>> Basically each DescribePixelFormat takes about 40-60 ms when running
>>>>>> without hardware acceleration because it calls 
>>>>>> LoadLibrary/FreeLibrary
>>>>>> for opengl32.dll every time.
>>>>>> So the fix is to cache the handle to the dll.
>>>>>
>>>>> It is needed even in case of d3d=true?
>>>>> (D3DGraphicsDevice extends Win32GraphicsDevice)
>>>>>
>>>>
>>>> Not really. Although I don't see any harm to it.
>>>> Anyway, I think that this fix could be made even more concise 
>>>> provided that we don't free the handle.
>>>> So I moved this code to the 
>>>> Java_sun_awt_Win32GraphicsDevice_getMaxConfigsImpl which is not 
>>>> called in case of d3d:
>>>>
>>>> http://cr.openjdk.java.net/~vadim/6477756/webrev.01/
>>>>
>>> Actually this is wrong as this function could potentially be called 
>>> many times resulting in the handle leak.
>>> I think the first fix is better even if it loads the dll in case of 
>>> d3d=true
>>>
>>> Vadim
>>
>> I've updated http://cr.openjdk.java.net/~vadim/6477756/webrev.01/ in 
>> place.
>> I left the code in the initIDs function. Given that it's called only 
>> once, I've simplified it to not use the static variable.
>>
>> Vadim
>



More information about the awt-dev mailing list