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

[Emil Velikov]

Hi all,

Another round of interesting bits and bulbs.

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.

  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.


* 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.


* 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.


  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.


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

Cheers,
Emil