ATI on Windows Speed, Context create & destroy

OpenGL Development JOGL Development
#1

Hi,

With JoGL since 1.1b4, on Windows, When you create and destroy GLCanvas, the speed can slow down drasticaly.

In fact, what’s happen, seem that the GLContext are not free, and the driver can’t create a hardware accelerated GLContext.

So the bug depand on the Video memory you have, the video resolution you have, and the size of GLCanvas you use.

For example, on my Dell 8600 with 128 Mo video Ram, and screen resolution of 1920x1600, I can create only 1 GLCanvas, not 2.

I have investigating the source code, and doing some test.
The problem seem to come from the WindowsGLContextFactory.checkForDummyContext method.
And more particulary on SetPixelFormat.
When the code go up to this line, the GLContext are not free.

If in the method WindowsGLContext. choosePixelFormatAndCreateContext you jump the checkForDummyContext, all is Ok.

Have you some idea ?
I’m currently investigating on native side, CreateDummyWindow.

#2

I tried modifying the WindowsGLContext implementation to not use the dummy OpenGL context and the TestContextDestruction demo still slows down after several swaps of the components on my machine (NVidia Quadro FX Go700). I haven’t tried on an ATI card.

If you could keep looking into this I think that would be really helpful. If you find a code change that seems to really speed things up or otherwise improve the behavior then please file a bug with the JOGL Issue Tracker or post here on the forums.

#3

Hi,

The bug I have doesn’t happen on NVIdia, only on ATI with verious version of driver.

The Slows down I speak, on our application, is more a freeze.
Before the bug a frame rate of 50, after one image each 10 secondes.

The application can be download on http://www.3designexpress.com , a trial version of 1 month exist. (Create a part, go to World, go to part…)

When I do the test with TestContextDestruction, on ATI,
I extend the first frame in order to have a full screen, I click on Toggle Frame 1’s component, twice, and the render speed is 1 frame each 2 seconds.

In fact the speed of the slow down seem to depends on the size of the GLCanvas and the video memory.

#4

Hi,

Okay guy,
I change in the C code, the CreateDummyWindow, with a return GetDesktopWindow();

HWND CreateDummyWindow( int x, int y, int width, int height ) {
RECT rect;
HINSTANCE hInstance;
DWORD dwExStyle;
DWORD dwStyle;
HWND hWnd;

// CD 23 02 2005
return GetDesktopWindow();

// …

  ZeroMemory( &rect, sizeof( rect ) );

And it 's look Okay for the bug.

I continue investigation.

NO !!!

Crash on NVIDIA, and same lags as 1.1b3.

Still searching…

#5

If you look in the documentation for the WGL_ARB_pixel_format extension, they specifically do not recommend returning the desktop window, but creating a new dummy window because you are only allowed to set the OpenGL pixel format of a window once.

#6

Hi,

Yes you’re right about the Desktop windows.
And it’s crash on NVIDIA.

One things, I note, on the TestContextDestruction,
in the init method the call to drawable.setGL(new DebugGL(drawable.getGL()));,
when the GLCanvas is add and remove,
this add a serie of DebugGL 1, 2, 3, 4, …

In fact GLContext call only one time the setGL(createGL());
even if a destroy, create happen !

So the GL contain the old Context !

Can we add in resetGLFunctionAvailability() ,
a call to setGL(createGL()); ?

#7

Thanks very much for tracking down that problem. The root cause of the slowdown really appears to have been just the creation of too many DebugGL instances. The OpenGL context is stored inside another object and only the internal context value changes when the OpenGL context changes, not the entire containing object, so the retaining of the old GL object should not be an issue. I’ve just checked in a fix to the TestContextDestruction demo as well as a couple of the other demos which had the same coding error; this fix will be present in the next beta.