Gerhard Wesp writes:
> > I know that threading inside an OpenGL context is considered to be a no-no,
> 
> Why?

You can think of OpenGL as a "state machine".  The sequence of calls
you feed into it determines the path that the state machine takes.
And that determines what get's rendered.

An analogy would be following directions from city A to city B.  You
are fed a seqence of commands "turn left", "turn right", "go
straight", etc.  If you follow these commands in the exact sequence
you recieve them, you will end up at the correctly place.

So imagine if you are getting your city to city directions from two
threads (or two people sitting in the back seat.)  If these two people
are *very* carefully working together to give you directions to the
same place, you could be successful.  But if these two people are
giving you directions to two different destinations, and worse, they
are interleaving their commands with each other, and you have no
choice but to honor them in the order you receive them, imagine the
chaos that could ensue.  You will most likely crash in the ditch when
you get a "turn left" at a place where there is no road going left,
and the best case scenario is that you don't arrive at either
destination.

It's very much like that in OpenGL.  If you have two threads sending
the card opengl commands to do different things, and these commands
get interleaved, who knows what you get as the end result, and more
likely you'll crash in the ditch before you get to any destination at
all.

Given all the complexities of threading, you will soon discover that
you are doing yourself a ***HUGE*** favor if you keep all the opengl
calls caged in a single thread.

> References?

Personal experience and advice from the experts.

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    curt 'at' me.umn.edu             curt 'at' flightgear.org
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

_______________________________________________
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel

Reply via email to