RFC/WIP: Retracing without explicitly linking to libGL

[José Fonseca]

On Fri, Dec 2, 2011 at 3:45 PM, Alexandros Frantzis
<alexandros.frantzis at linaro.org> wrote:
> On Fri, Dec 02, 2011 at 08:06:26AM +0000, José Fonseca wrote:
>> I've pushed a follow on patch that tries to do the right thing, namelly
>> dlopen the right libGL/GLES*.so on demand. I also tried to document this
>> better.
>>
>> Let me know if it works ok.
>>
>> Jose
>
> Hi Jose,
>
> I have pushed some fixes/improvements at:
>
> http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/glws-egl-xlib-fixes
>
> This branch is based on 'glproc-cleanup', although I am not sure if all
> the changes belong there conceptually. Here is a summary:
>
> 1. Use libGLESv2.so.2 as the OpenGL ES 2.0 library SONAME.
> 2. Cast native types to EGL types when calling EGL functions.
>
>  These are straightforward.

I've applied these two and merged into master.

> 3. Add 'profile' parameter to glws::createVisual().
> 4. Try to find the best matching EGL visual according to the profile.
> 5. Recreate the EGL visual to increase chances that it supports the requested api.
>
>  The existing mechanism for the selection of visuals could produce
>  strange results in some cases. For example, on systems that support
>  only ES1 and ES2, an ES1 visual was _always_ selected if there were
>  no ES1|ES2 visuals, even if we actually needed an ES2 visual.
>
>  By making the glws::createVisual() function aware of the requested
>  profile, we can provide better matching visuals.

Finding a better visual sounds good.

But the current way of recreating the visuals introduces dangling
pointers on multiple contexts, as previous context/drawables wll be
pointing to a non-existing visual structure. I see two solutions:
1) delay creating the global glws::Visual until one is needed
2) reference count glws::Visual

Note that the current global visual is hack -- my plan was always to
recreate visuals that match what the application used --, but never
had time to do any better.

Jose