[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
wglGetProcAddress(...)
wglChoosePixelFormat(...)
....
wglMakeCurrent (device_handle, NULL);
wglDeleteContext (gl_rendering_context);
ReleaseDC(device_context);
DestroyWindow(window_handle);
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
context.
> 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.
Cheers
Emil
> Any feedback would be great. Meanwhile I will send out a few misc/cleanup
> patches :)
>
> Cheers,
> Emil
>
More information about the waffle
mailing list