On 17.05.16 21:44, Vadim Pakhnushev wrote:
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...

Thanks for clarification, looks fine.


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




--
Best regards, Sergey.

Reply via email to