PBuffers sharing textures without a Display()

[Spasi]

This would be useful in order to share the Display context between subsequent Pbuffer allocations in order to keep the textures when the Pbuffers get lost. Nice, isn't it ?

Unless I'm misunderstanding what you're doing, this won't be necessary. If the pbuffer contents get lost, only contents of the buffers (color, depth, etc) associated with it are lost, not the textures that live in its context. It's a problem only when you're using render-to-texture, since the buffer contents *are* the texture(s).

Could you please confirm that getPbufferCaps doesn't work?

[elias]

Pbuffer.getPbufferCaps() should work again now.

- elias

[javazoid]

I'll check the missing textures problem again.

Anyway, what about the invisible Display feature ?

Games published by our own members! Check 'em out!

[elias]

I'll check the missing textures problem again.

Anyway, what about the invisible Display feature ?

If the textures are not lost, what do you need the invisible display for?

- elias

[javazoid]

Suppose you have a Swing app that wants to hide/show a preview panel (the Display).

[elias]

In that case I'd rather prefer a proper AWTGLCanvas (maybe even that from JOGL) that you can embed.

- elias

[javazoid]

Very nice! Will the above end up into an RFE ?

[princec]

It's an often-requested feature that no-one's quite had time to do yet. My gut feeling is that it won't be too hard to do but using it will involve learning about threading and AWT properly

If it gets done it'll be in another little subproject like the SWT canvas adapter.

<edit>This functionality is already available by the way, if you use JOGL to create your canvases. You can subsequently do all your rendering using the LWJGL API. (Keyboard and Mouse of course won't be available, you'll have to use AWT or JInput)

Cas