wine/ graphics/x11drv/xfont.c graphics/x11drv/ ...

[Lionel Ulmer]

> Do you really need to lock all GL calls, or is it just to protect
> access to d3d internal structures? 

I do not lock at the individual GL call level but rather at the 'internal
API' level (for example, to draw some primitives, I do not lock on each
glVertex call, but at the API function level which does the drawing).

And, yeah, it also serves to protect internal structures (why add a new lock
when you already have one that you needed to call).

> The GL libraries themselves should be thread safe right?

Well, this is a point that I never really investigated (especially when two
threads are sharing the same GL context). For example, in Wine, we never
actually set the current GL context for all threads, only for the one
creating the D3D object... And still, multi-threaded games like DungeonSiege
work like a charm (this is maybe due to the second thread 'inheriting' the
GL context as long as one does not call glXMakeCurrent on a new context).

But the real issue is that they share the same context and that we need to
change GL states to emulate some of D3D's quirks. So some game (like
DungeonSiege) which does 3D rendering in one thread and 2D in another thread
would have the lock / unlock thread break the GL rendering states ... and
would lead to utter mess on the screen (as I saw for myself when I started
debugging this game when some locks were missing :-) ).

I have no idea when I will have time to replace the X11 lock usage by a
special D3D lock (I was planning to hack on more fun stuff this week-end :-)
).

Note that the GL locks can be removed from the OpenGL code (I just need to
re-generate the thunks).

           Lionel

-- 
		 Lionel Ulmer - http://www.bbrox.org/