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

[Chad Versace]

On Wed, Jun 04, 2014 at 01:24:38PM -0700, Jose Fonseca wrote:
> 
> 
> ----- Original Message -----
> > On 02/06/14 19:55, Chad Versace wrote:
> > > On Sat, May 31, 2014 at 12:02:10PM -0700, Jose Fonseca wrote:
> > >>
> > >>
> > >> ----- Original Message -----
> > >>>
> > >>>
> > >>> ----- Original Message -----
> > >>>> 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);
> > >>>
> > >>> Yep.
> > >>>
> > >>>
> > >>>
> > >>>>
> > >>>> 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.
> > > 
> > > 
> > > If you could rewrite this problematic portion of Waffle's API, how would
> > > you design it? I'm asking so that, if we do redesign Waffle's API one
> > > day, it can better accommodate Windows and Mac.
> > > 
> > > One requirement of any API redesign, though, is to preserve the ability
> > > to create a context and render into it without creating a throwaway
> > > surface, as in EGL_KHR_surfaceless_context. (Through-away surfaces are
> > > ok as long as they are internal to Waffle).
> > > 
> > If I understand things correctly surface(egl)/drawable(glx) are not as
> > clearly
> > separated in wgl. At least not initially.
> > 
> > Redesign of Waffle's API sounds like an overkill imho, as the only thing we
> > need is an easier way get from context/config data to window. Otherwise
> > wcore_(context|config|window) will be dummies and everything will be stored
> > in
> > a wcore_display wrapper (wgl_display).
> > 
> > Perhaps the following rough flow illustrates things a bit better
> 
> 
> Abstracting across many platforms is always complicated, and even more
> if we can't run tests on all of them.  So even if we end up
> redesigning, it might be better to first get windows to work (even if
> that requires a few hacks/assumptions) first, so we can run
> tests/examples.

I totally agree. Let's focus on getting Windows working with the current
API, even if it requires imperfect hacks.

> > glx (in the following example window is optional)
> >    display > glx > create_context > window > gl*
> > 
> > wgl (here window is the root, i.e. think of (wgl)window == (glx)display)
> >    window > create_context > wgl/gl
> > 
> > Currently I shove everything in wgl_display, although a slightly cleaner
> > approach might be better.

This makes sense to me.

>From my uninformed perspective, it seems that shoving the Win32
window/display/device/whatever into wgl_display is the best approach.
But you and Jose likely know better than me. Whatever you need to do to
get it to work.