GLX compatible pixelformats

[Brian Paul]

Roderick Colenbrander wrote:
> Hi,
> 
> For some time I have been rewriting Wine's Opengl32 layer. Right now I'm 
> fixing our pbuffer code and because of that I have a question about GLX 
> pixelformats.
> 
> First a little Wine background. Windows programs use GDI  in combination with 
> a display driver for rendering. Wine contains a X11 driver for rendering. Due 
> to various limitations of Wiine's X11 driver we are limited to a single X 
> Visual. This visual is created at 'startup' and is GLX compatible (we try to 
> find a RGBA format with double buffering, 8bit alpha, 8bit stencil ).
> 
> For most OpenGL programs this single pixel format isn't a very big limitation 
> as on Windows programs aren't guaranteed to get what they want anyway. If 
> they ask a 32bit format they can in theory get a 8bit format back, so it is 
> normal to verify what you got.
> 
> The problem lies in pbuffers in which case the pixel format requirements are a 
> bit more strict. The functions which programmers use are similar to 
> glXGetFBConfigs and friends which searches for formats which meet you 
> requirements. In general programs expect to get atleast one format back.
> 
> Our issue is that we want to advertise as much 'compatible' pixelformats as 
> possible (also for things like multisampling and more). I wrote a small test 
> app which created a pixmap/pbuffer and checked for each format if it was 
> compatible with the format of the GLX Context (I created a context which met 
> the same requirements as I mentioned for Wine)
> 
> I got about a dozen of 'compatible' formats with similar R/G/B/A, depth and 
> perhaps other things in common. I tried the same program (both using a 
> direct/indirect rendering context) on the radeon dri drivers (rv250) and 
> using the fglrx drivers. Further users of different cards tried it too.
> In case of pixmaps it found at most one compatible format and the pbuffers 
> test failed (most drivers don't support pbuffers).
> 
> Based on my nvidia tests I expected to find a few compatible formats. Are 
> there some heuristics which I can use for finding compatible formats (without 
> testing)? What's the best way on how to do this? What's the definition of 
> compatible? (the specs are vague)

So you're looking for compatibility between a GLX context and one or 
more windows plus one or more pbuffers?

Off-hand, I don't recall that there has to exist any pbuffer formats 
that match a given window's pixel format.  Though, that would probably 
be a rare situation.

The definition of compatibility between a rendering context and a 
drawable is a bit vague.  Though, with recent developments like 
framebuffer objects, the rules are getting relaxed a bit.

In Mesa, the check_compatible() function in src/mesa/main/context.c 
shows how we test for compatibility between a context and a drawable.

-Brian