"Fast" Pbuffers implemented

[spasi]

OK, pbuffers with unique context, without rtt, work great now. But it still hangs with rtt and now I get a "Could not make pbuffer context current" with context sharing (with & without rtt).

I'm starting the pbuffer test now...

[spasi]

The tests are ready. They are in org.lwjgl.test.opengl.pbuffers. Usage: PbufferTest <mode>, where mode can be one of 1-4, to try the different techniques.

From the four tests only the second doesn't run, it hangs just like in Marathon. The others are fine.

[elias]

That was an easy one, the test number 2 works now, except that the inner colored square is never shown like in the rest of the tests. Could you verify that this is intended?

- elias

[spasi]

No, it's not. Post a new build and I'll check it out. I couldn't test that one at all.

[elias]

Here you go:

http://odense.kollegienet.dk/~naur/lwjgl-20040726-2.zip

I had to disable the single buffering stuff for the shared context path, because I discovered that the pixel format has to match exactly, not just the buffer depths like in GLX.

- elias

[spasi]

OK, fixed it. I was using the back buffer instead of the front.

So, to sum up, when sharing the display context the pbuffer is forced to have the exact same pixel format and be double-buffered, right? And when having a new context, you can choose whatever pixel format you want and it will be single buffered (GL_FRONT_LEFT only). Am I correct?

[elias]

Mostly correct. I updated the docs, and as they state, single buffered pbuffers are always preferred, but if that fails, you can get a double-buffered one. In practice, it means that in Linux where the GLX spec is less restrictive, you can get a single buffered pbuffer with a shared context (but still same buffer depths as the display), but in win32 you will always get a double-buffered one. For unique context pbuffers, you will most likely get a single-buffered pbuffer, but if that is not possible, a double-buffered format pbuffer could be created.

- elias

[spasi]

Nice. What about the different function addresses? I guess that will never happen in a standard game, but will we do something about it? Just to cover an unusual usage of the library. Probably not, right?

[elias]

Already converted to the Assumption: "Contexts will never have different function pointer sets". So the pointers will only load if they're not loaded already.

- elias