SWT and LWJGL

Started by Madsie, March 07, 2004, 15:33:44

Previous topic - Next topic

Madsie

I'm looking into using LWJGL in SWT. It looks good! The application I'm building is using multiple viewports, but some of them should share textures and other stuff.

I'd like to know if contexts can be shared among canvases? From the discussion I've read here it looks like the SWT canvas is bound to its own context.

The general LWJGL OpenGL methods seems not to care about context, but simply directly invokes the C API, so if this is not supported, I suspect I could just code my own canvas with context sharing and that stuff, and then for all the actual rendering calls I should be able to use LWJGL.

princec

That's right. In the next release, due out in a few weeks, we've got a GLContext class that simply allows you to use any existing context with LWJGL, and you can happily render wherever you like using the GL APIs.

Cas :)

Madsie

Thanks for your reply Cas! I'm eagerly awaiting the next release  :D

I'm a little unsure if you meant that the existing SWT canvas can handle multiple instances with shared context?

fbi

You are definitely right...
I'm the one who coded the SWT stuff...so it's quite sure you can do what you said  :D
In the current implementation for example you have a setCurrent method in order to select the canvas as the current context.
So you can have multiple contexts...
Anyway if you have other wishes/needs for the SWT Canvas lemme know about it  :D
SWT is damn cool  :twisted:

Madsie

Hey fbi, looking forward to that SWT canvas!

I'm not sure that we are talking about the same thing though  :wink: There's two context types, the GDI context (that can't be shared) and the rendering context (can be shared).

What I'm asking is if the same rendering context can be shared among multiple canvases?

Currently I'm using my own thing (GUI and everything coded in OpenGL), but I want to switch to SWT to get native laf on the different platforms (as well as to lower the driver requirements). Here's a shot of the none-SWT version: http://www.madsie.com/freestyle/shot1.png

fbi

If I guess right you're referring to the GL rendering context (what's called HGLRC under Windows)...and if this is right....ok I gotta repeat what I said  :D
Because the SWT/LWJGL is designed so that you can use the GL the way you prefer: in your case for example I imagine you'd like to render something from different views.
This is not only possible but it's easy  :wink:
If you wanna test it on your own I could send you a code snippet  that shows how to render exactly the same thing in two different canvases.

Madsie

I hate to keep going on, but I still think we're talking about different things  :wink:

If canvases don't share rendering contexts, they don't share textures, display lists, VBOs etc. Rendering the same in two different canvases without a shared rendering context is easy, but not very efficient or memory preserving.

I read your comment refering to "setCurrent" as if you can't share a rendering context. So I would be very glad if you could show a short snippet that creates two canvases with the same rendering context  :D

fbi

OK...sorry my fault!  :lol:
I wrote a "current" for "future"...sorry I'm damn hard working on a VRML demo  :wink:
Ok...I clarify things a bit.
In the current implementation I talked about in the forum, the context is tightly bound to the SWT Canvas.
In the future one (which will support Linux as well) the setCurrent I was talking about will have a rendering context as an argument (or sort of...)  :D
I should talk with the other guys (I was investigating 0.9 code a bit today) on how to do that but I would like to let the new context creation as an option.
Sorry for the misunderstanding...shared context was something I was always thinking about  :D

Madsie

Thanks for taking the time to reply  :D

I would think that specifying a context in the SWT canvas constructor would be flexible enough for all while keeping it simple and fast (if no context is specified then the SWT canvas creates its own). This way setCurrent can also be kept simple and fast.