[cairo] WGL backend for glitz?

[David Reveman]

On Tue, 2004-07-06 at 17:40 +0300, Tor Lillqvist wrote:
> Hi again,
> 
> I have now been hacking on a WGL backend for some evenings. As was
> suggested, I made copies of the *glx* files and started from that. I
> don't have yet any code that actually does anything (not all of my
> *wgl* files even compile currently). But at least I think I have some
> understanding how it all is supposed to hang together.

Great!

> 
> Except for some points... Mainly the thread stuff. Is the thread
> support supposed to work in the GLX and AGL backends, or is it just an
> outline to be fixed later? (I am looking at glitz-0.1.5.)
> 
> The glitz_glx_thread_info_get() function allocates a thread_info
> struct and sets it as a thread-local value for the info_tsd key only
> once, the first time it is called. Other times it fetches the
> thread-local thread_info with xthread_get_specific(). But where is the
> thread-local thread_info allocated and set for the other threads?
> Doesn't xthread_get_specific return NULL if no value has been set for
> the key, which will cause a crash in the caller of
> glitz_glx_thread_info_get()? Ditto for the AGL backend.

yes, I think you're right, the current thread initialization code is
probably broken, I'll fix it as soon as possible.

> 
> Anyway, on Win32 the equivalent of xthread_key_create() (TlsAlloc())
> doesn't take any destructor function. A workaround would be to have a
> thread function wrapper in glitz, and require that threads that are
> going to use glitz have that as their thread function.
> 
> Another workaround would be to require that glitz-wgl is built as a
> DLL (a very reasonable requirement IMHO), and write a DllMain() to
> watch thread creation and destruction, and call the destructor for
> thread_infos as needed. (This approach does have some problems,
> though. Google for USENET postings about TlsAlloc and destructor.)
> 
> Which sounds better? Or should I just ignore threads on Win32 for
> now...?

I think you can ignore threads for now, we'll figure out a good solution
in the end.

> P.S:
> 
> I am leaving for vacation for three weeks on Saturday. Even if my WGL
> code isn't working yet by then, should I submit it for inclusion? Or
> do you prefer to have a look at it only when it actually works?

It's up to you, If you have something that people can play with, then I
think it would be a good idea to post a patch. I'd like to have a look
at it as it is. If there's any specific problems with the wgl backend,
then it's good for me to know, just so that I don't make things worse
for you.
 
-David