zahirtezcan's picture

Context without a Control

There is a discussion on creating multiple contexts here. It tells me that creation of a context is done via construction of a GLControl. Is it possible to create an OpenGL context without a GLControl?( Afaik, windows needs an HDC to create wglContext which may require a window handle or a GDI (i.e. Bitmap) handle. )

Is it possible to just create a shared context for allocation of buffers/lists without a need of a control? I mean, you load resources and allocate on GPU by multithreaded I/O etc. and just draw on one surface. (Such surface is created by a GLControl). This just came into mind from this article. Since, display lists exist in OpenGL from the very beginning; i thought there should be some support on multithreaded (multi-shared context) rendering. But, i couldn't achieve it without creation of a rendering surface.


Comments

Comment viewing options

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

There is a discussion on creating multiple contexts here. It tells me that creation of a context is done via construction of a GLControl. Is it possible to create an OpenGL context without a GLControl?( Afaik, windows needs an HDC to create wglContext which may require a window handle or a GDI (i.e. Bitmap) handle. )

You are right that Windows need an HDC to create an OpenGL context. However, using the HDC of a GDI bitmap will result in non-accelerated context (Microsoft's GDI renderer), which cannot be shared with accelerated contexts.

Enter the GLControl: the GLControl creates an invisible window and uses its handle and HDC to create an accelerated context. If you don't attach the GLControl to a Form, the GLControl will remain invisible, but shared with your regular OpenGL context.

Quote:

Is it possible to just create a shared context for allocation of buffers/lists without a need of a control? [...] But, i couldn't achieve it without creation of a rendering surface.

OpenGL *requires* the existence of a rendering surface. In general, there are three distinct kinds of surfaces: window surfaces, pixmaps and pbuffers.

OpenTK only supports window surfaces right now. Pbuffer surfaces are complex to create and use (and not to mention slow) and have been superseded by FBOs. Pixmap surfaces are generally not hardware accelerated for OpenGL rendering. This leaves window surfaces as the only viable option.

GLControl provides the easiest method to create a context for offscreen rendering. OpenTK trunk contains more options, but those are still under development and are not exposed to the public API.

There's one last possibility that might work. I have not tested this, but it should be possible to create a single GLControl (for your visible context) and use it to create a second GraphicsContext. The GraphicsContext class needs an IWindowInfo instance, which you can obtain from a GLControl using OpenTK.Platform.Utilities.CreateWindowInfo(). Create the secondary GraphicsContext in the main thread, make it current on your background thread and use it to load resources, compile shaders etc.

zahirtezcan's picture

Thank you for the guidance. i'll try the 'Utilities' for creation of my context. But, just to comment out that this looks like a 'hack' to me. I'd rather have a 'non-drawable' (creation and manipulation of server side objects are allowed but commands like 'DrawElements' are just 'INVALID_OPERATION') context for multi-threaded usage.

As you have said, requirement for the existance of a surface disables the option. But, i *hope* they will add some extension for this kind of context creation, that Direct3D will use such support of drivers.

the Fiddler's picture

Khronos is expected to announce OpenGL 3.2 on 5 August, which is likely to have have support for some form of multithreaded rendering.