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 > _______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle