[waffle] [GSOC 2014] How to deal with non win32 api, wgl(Create, Make)Context depends on existing window

Emil Velikov emil.l.velikov at gmail.com
Wed May 28 12:37:48 PDT 2014

On 24/05/14 20:28, Emil Velikov wrote:
> Hi all,
> Another round of interesting bits and bulbs.
Bit of an update:

> The email came out a bit longer than expected, although it provides a decent
> list of possible solutions. Let me know which one you'll go with.
> Four topics sorted by priority - high to low (based on my humble opinion)
> * ChoosePixelFormat - close yet quite different across platforms.
>   - glXChoosePixelFormat    - depends on display (matches waffle's model).
>   - CGLChoosePixelFormat    - no dependencies.
>   - {wgl,}ChoosePixelFormat - depends on a device_context/existing window.
To make things better, wgl functions depend on a current context as well. The
recommended way of doing things under windows seems to be the following:

   window_handle = CreateWindow(...)
   device_context = GetDC(window_handle);

   gl_rendering_context = wglCreateContext(device_context);
   wglMakeCurrent (device_handle, gl_rendering_context);

   // any of the following

   wglMakeCurrent (device_handle, NULL);
   wglDeleteContext (gl_rendering_context);


AFAICS waffle is unique wrt other projects (apitrace, epoxy, glut) as it
allows the PixelFormat to be called prior to the creation of either window or

>   Options:
>     - Create a window, choose format, destroy window.
>           No guarantee that the function will behave the same for another
>           window/device_context.
>     - or, create window, choose format, reuse window on waffle_window_create()
>           Sanest solution. If windows is not created just make one (i.e.
>           waffle_config_choose is not executed before waffle_window_create).
>     - or, store the attributes, and invoke ChoosePixelFormat as
>       waffle_window_create is executed.
>           What if code-flow depends on waffle_config_choose's return value ?
>     - or rework waffle API ... (no, please no)
>   Suggestion:
>     "Cache" the window, and reuse it on waffle_window_create.
I'm planning to give the "cache the windows" a stab soon, although
I would greatly appreciate if anyone has an opinion/comment.

> * CreateContext, MakeCurrent - same story as ChoosePixelFormat :\
> * Thread-safe and Co.
> AFAICS it's used to provide thread independent waffle error info. Have I
> missed something ?
>    - strerror_r is depreciated in favour of strerror_s. MS claims that the
>      former is not TS, while *nix man page disagrees.
>    - Current mingw-w64 build does not work on Win XP - missing strerror_s.
>      Fix landed in mingw-w64 trunk ~a few weeks ago.
>        - Back-port commit and build things with custom mingw_w64
>        - or, port the commit over to waffle ?
>   Suggestion:
>     Port over to waffle.
The commit addressing strerror_s + mingw-w64 + WinXP has been backported to
the stable branch of mingw-w64. We can mandate that version (to be released)
as the minimum requirement in the readme/build-scripts.

> * Library dependencies, etc. (low priority)
> libwaffle-1.dll depends on mingw-w64 dlls - should we nuke the dependency,
> ship them in the zip or leave it to the user/dev ?
>   Library:
>     libgcc_s
>       __emutls_get_address
>       __udivdi3
>       __umoddi3
>   Options:
>     - Static link libgcc_s, generally not bad idea
>     - or, rework waffle ?
>           Split merged_version or move to (major << 8 | minor) for the
>           wcore_config_attrs_version_* helpers - will nuke the last two.
>           No idea how to nuke __emutls_get_address.
>   Suggestion:
>     Split to separate major/minor.
As spotted by Jordan, there should be no implications of static linking with
libgcc[1]. I've added a couple of lines to the build and so far it works like
a charm.

[1] https://www.gnu.org/licenses/gcc-exception-3.1-faq.html

>   Library:
>      libwinpthread-1
>        pthread_key_create
>        pthread_mutex_lock
>        pthread_mutex_unlock
>        pthread_once
>        pthread_setspecific
>   Options:
>      - Static link
>      - or, rebuild mingw-w64-gcc with --enable-threads=win32
>      - or, rework current code (open to suggestions)?
>   Suggestion:
>     The above list states my order of preference.
My initial assumption was that the library is GPL 2 and/or 3 based.

Closer look revealed that it is X/MIT and 3-clause BSD licensed, and afaik
there should be no problems with distributing the binary (pending the no
advertisement & stating it's license).

Meanwhile I did take a look at how greatly piglit depends on waffle. Nicely
separated codebase, falling back to glut whenever waffle is not available.

A couple more patches have emerged as well
 * Autodetect the targets under linux, and
 * Remove the restrict definition from waffle.h

which I would like to test a bit more and send it out for review.


> Any feedback would be great. Meanwhile I will send out a few misc/cleanup
> patches :)
> Cheers,
> Emil

More information about the waffle mailing list