Hello,

I was wondering if anyone knew a good method to have wglMakeCurrent work
properly in a possibly multithreaded object-oriented environment. The
problem is thus:

A context cannot be current in multiple threads.
Contexts exist in the first place.

To handle the second of these problems, I had thought to include the current
context as a private static value. At every call (actually, I was thinking
of converting everything to tokens, buffering those, and only actually
calling when necessary, but still) it would check if the current context is
the one being used, and if not make the new one current.

Now the problem. Multiple threads. The context value (and token buffer)
could be locked when everything is being done. This would make it
thread-safe, yes? Sadly, the former problem ruins this. The new thread can't
get the context, because the old thread still has it. Any good way to handle
the handoff?

The only option I see is to spawn a thread for OpenGL and pass it tokens
(one thread per context), using an event object for notification. I don't
like this method, though. :-(

Any ideas?

Thanks! :)
Jim Bellinger

I'd do that, except, as per the wglMakeCurrent documentation:

Before switching to the new rendering context, OpenGL flushes any previous
rendering context that was current to the calling thread.

So, doesn't that mean this method would be hopelessly slow? :-/ Especially
since I may have it doing this quite often...

"Roger Rowland" <see.sig@bottomof.message> wrote in message
news:1061747477.95841.0@ersa.uk.clara.net...
> Maybe I misunderstood your problem, but I have a situation where I have a
> multi-threaded app - each thread of which uses a common context. Not sure
if
> this is the same as you?
>
> Anyway, it works fine for me. Each thread only acquires the context
> immediately before it needs it and releases it again immediately
afterward.
> Access to the context is made via a critical section, so only one thread
has
> the context active at a time. The thread that wants the context waits at
the
> EnterCriticalSection() until the thread that has the context calls
> LeaveCriticalSection().
>
> Does that help any?

Well there certainly is a performance hit, but if you're switching contexts
then you're switching contexts.

Ain't no way around that.

Does your design really *need* multiple contexts? In my app (as described)
there's no noticeable performance problem in operation although by measuring
the frame rate I can see that it *is* affected.

-- 
----------------------------------------------------------------------------
-----------
EMail: roger dot rowland at rmrsystems dot co dot uk
"James F. Bellinger" <NaturesEthereal@do.not.spam.me> wrote in message
news:%j72b.2724$l41.1194191@twister.neo.rr.com...
> I'd do that, except, as per the wglMakeCurrent documentation:
>
> Before switching to the new rendering context, OpenGL flushes any previous
> rendering context that was current to the calling thread.
>
> So, doesn't that mean this method would be hopelessly slow? :-/ Especially
> since I may have it doing this quite often...
>
> "Roger Rowland" <see.sig@bottomof.message> wrote in message
> news:1061747477.95841.0@ersa.uk.clara.net...
> > Maybe I misunderstood your problem, but I have a situation where I have
a
> > multi-threaded app - each thread of which uses a common context. Not
sure
> if
> > this is the same as you?
> >
> > Anyway, it works fine for me. Each thread only acquires the context
> > immediately before it needs it and releases it again immediately
> afterward.
> > Access to the context is made via a critical section, so only one thread
> has
> > the context active at a time. The thread that wants the context waits at
> the
> > EnterCriticalSection() until the thread that has the context calls
> > LeaveCriticalSection().
> >
> > Does that help any?
>
>

I'd like to be able to support them, at least. Performance with one needs
to be quite good, with multiple can be reasonable. Perhaps the best option
would just be to marshal everything around as tokens, with a dedicated
thread for each context..

"Roger Rowland" <see.sig@bottomof.message> wrote in message
news:1061901273.84581.0@iris.uk.clara.net...
> Well there certainly is a performance hit, but if you're switching
contexts
> then you're switching contexts.
>
> Ain't no way around that.
>
> Does your design really *need* multiple contexts? In my app (as described)
> there's no noticeable performance problem in operation although by
measuring
> the frame rate I can see that it *is* affected.

Yes, I guess the best think to do is try it. You might find that there's
just as much overhead caused by thread synchronisation as there is from ogl
context switching. Depending on the app and expected hardware, this may or
may not be a problem.....

Good luck :-)


"James F. Bellinger" <NaturesEthereal@do.not.spam.me> wrote in message
news:B4Q2b.14967$l41.2904673@twister.neo.rr.com...
> I'd like to be able to support them, at least. Performance with one needs
> to be quite good, with multiple can be reasonable. Perhaps the best option
> would just be to marshal everything around as tokens, with a dedicated
> thread for each context..
>
> "Roger Rowland" <see.sig@bottomof.message> wrote in message
> news:1061901273.84581.0@iris.uk.clara.net...
> > Well there certainly is a performance hit, but if you're switching
> contexts
> > then you're switching contexts.
> >
> > Ain't no way around that.
> >
> > Does your design really *need* multiple contexts? In my app (as
described)
> > there's no noticeable performance problem in operation although by
> measuring
> > the frame rate I can see that it *is* affected.
>
>

"James F. Bellinger" wrote
> I was wondering if anyone knew a good method to have
> wglMakeCurrent work properly in a possibly multithreaded
> object-oriented environment.
[snip]

We have implemented a graphics framework that supports object-oriented,
multi-window, multi-threaded animated 3D graphics programming in OpenGL
with programmable GUI on Windows platforms.  The interface routines that
are involved with OpenGL 3D graphics are essentially four entry points
implemented in the form of DLLs: Initialize (to setup rendering context,
lighting, etc.), Reshape (to handle resize requests), Display (to render
the scene), and Select (to allow user selections using a mouse).  The
first three are similar to those described in the end of chapter 1 of the
red book while the last one is our abstraction to allow a user to select a
point, a line, or a rectangular region with mouse operations.  We have a
graphics class that contains the data structure for the operational data
(rotate, translate, etc.) and the above four DLL function entry points.
Under the hood, however, we have a graphic window class that handles the
creation and maintenance of its instances (display windows) and calls the
four routines when necessary.  In fact, these four routines are triggered
by user messages, which could be generated by the Windows framework
(resize, paint, mouse ops, etc.) or by numerical simulation routines when
a screen update is needed.  Yes, the user can drag/rotate any of the 3D
scenes in the graphic windows while the animation is running.

All of the 3D graphics routines are executed in the GUI/Main thread while
the worker thread (numerical calculations) sends requests (messages) to
the GUI thread to refresh/render the window.  The device and the rendering
contexts are stored in the graphic window class (one each per window
instance).  You may wonder how efficient the graphics operations can be,
given the complexity of multiple windows, multiple threads, context
switching, DLL loading and execution, user interactions, working with
other applications, etc.  Well, you can download the software and try it
out on your own computer.

Here are some links you may find interesting:
http://protodesign-inc.com/sg_exStart.htm#solid - for some screenshots and
explanations of an example project; source code (in Microsoft Visual C++
or Compaq Visual Fortran) of the entire DLL routines are included.
http://protodesign-inc.com/files/SGtutSho.pps - a PowerPoint slideshow,
which contains some architectural diagrams of the framework and the
run-time environment.
http://protodesign-inc.com/doc/SansGUI/class_graphics.htm - the reference
page of the graphics class that is used for communications between the
framework and the routines that use OpenGL.

If you look at the source code of the DLL routines, you will find no
::SwapBuffers() nor ::wglMakeCurrent() call (they are not standard OpenGL
routines, anyway :-) because they are done by the framework, which also
handles printing, copying to clipboard, and exporting to bitmap or JPEG
image files.

-- 
Best Regards,
Greg Chien
e-mail: remove n.o.S.p.a.m.
http://protodesign-inc.com