gqmelo glx: delay GLX drawable destruction when window is destroyed
66bba36 Apr 4, 2016
glx: delay GLX drawable destruction when window is destroyed
This basically mimics Mesa behaviour when direct rendering is used.
This problem happens on the following scenario:

- Create win1
- Create win2
- Create ctx
- MakeCurrent win1 ctx
- MakeCurrent None NULL
- Destroy win1
- MakeCurrent win2 ctx

When using indirect rendering, on MakeCurrent NULL Mesa still keep
some association between the context and the framebuffer used by
win1.

Then on win1 destruction the GLX drawable is freed, but nothing is
done about the framebuffer.

When binding ctx to win2, sometimes the new created drawable is
allocated on the same address as the destroyed one. And as the
context still has a reference to the old framebuffer and the
drawable is "the same", the framebuffer is reused.

When this situation happens nothing is ever rendered to win2.

Mesa direct rendering avoids that (not sure if intentionally)
by destroying the first DRI drawable only after the second
is created.
66bba36