oyvindra's picture

Shared State between glControls

I am currently using four glControls in my modeling application, and I wonder whether there is some way to share state between them.

The reason I ask is because I am currently selecting objects by color, and that requires quite a bit of enabling and disabling when picking. In addition, I just changed my code to use VBO's and my own NURBS tesselator, and now all of the state changes in all the viewports are confusing me... Especially when it comes to lighting and light position for four viewports.

- Øyvind


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

By default, contexts are created with shared state. This includes textures, VBOs and display lists, but I do not think it includes the viewport or other similar state. Maybe someone more experienced can clear this up?

puklaus's picture

Im not experienced with these, but are threaded applications
sharing opengl data too? or coding "checks" whenever other thread can safely share data with other thread (or "send it")
is the way?
(example: some loop on thread one and other thread listening windows.forms)

Am I way too lost in this? (hadnt do like this never before)

the Fiddler's picture

What I meant to say is that OpenTK's GraphicsContexts enable data sharing by default. If you create multiple contexts (one per thread), OpenGL data will be shared among these.

The OpenGL spec defines what data is shared, but it's not a light read! Even worse, you can't assume that something is shared without reading the specs. For example VBOs are shared, but VAOs are not! (VAOs were introduced in OpenGL 3).

I would generally advise to steer clear of multiple contexts. They are complicated to setup, complicated to work with and they don't really thread all that nicely. Shader linking for example - seemingly a good target to offload to a secondary context, but it seems to block all contexts. Same thing with display lists. This depends on your drivers, of course - which is yet another reason to avoid multiple contexts.

OpenGL provides some methods to load data asynchronously, i.e. use a single GraphicsContext and feed it data from a secondary thread. Look up GL.MapBuffer (for loading VBO data) and PBOs (for texture data). If loading performance becomes an issue, these are worth looking into.

objarni's picture

oyvindra: I would use GL.Viewport to "simulate" multiple GLControls instead of having several controls.