RFC/WIP: Retracing without explicitly linking to libGL

[Alexandros Frantzis]

On Sat, Dec 03, 2011 at 10:29:37AM +0000, José Fonseca wrote:
> 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

Another idea is to create and store 3 visuals (i.e. make
glretrace::visual an array of Visual *), one for each Profile. When a
visual is needed, try to guess the best one to use based on the
available (limited) information. Still a half-measure compared to what
you are describing below, but I think it's clean and certainly more
flexible than what we have now.

I have uploaded a prototype of this approach here:

http://git.linaro.org/gitweb?p=people/afrantzis/apitrace.git;a=shortlog;h=refs/heads/retrace-per-profile-visuals

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

I guess that for this to work, extra information about the used configs
(attributes etc) needs to be logged at tracing time. Does the
tracer/tracing format have support for something like this?

Thanks,
Alexandros