@rbernon I have started exploring the behavior of `wglChoosePixelFormatARB` on real windows drivers. I created a tool to let me exercise the function from the command line: https://gitlab.collabora.com/alf/wglchoose, and used it on Win10 with Intel and AMD graphics.
I have attached the results ([amd.txt](/uploads/daa1fc7b3fc6f331bf48864390ae6154/amd.txt) and [intel.txt](/uploads/beeccb73ad6796b400d7b6bcefa62ec7/intel.txt) of running [wglchoose.ps1](https://gitlab.collabora.com/alf/wglchoose/-/raw/master/wglchoose.ps1) from the above repository, which just invokes `wglchoose.exe` with various attribute lists that I thought might be interesting. Unfortunately, I don't have access to NVIDIA graphics, so it would be great if someone could run the above tool on NVIDIA and provide some results to get a more complete picture.
Some terms: * **id order**: the pixel format ordered by increasing pixel format id * **nil order**: the pixel format order as returned by `wglChoosePixelFormatARB` with an empty attribute list.
The first results indicate that sort order and how attributes affect it is driver dependent. Here are some first notes after going through the logs:
AMD ---
The nil order is the same as the id order. Specifying attributes may change the relative order of pixel formats.
This seems to be the overall sorting precedence, and per-attribute sort order if the value for an attribute is not specified:
* supported surface: window(+bitmap) then bitmap-only (relative ordering with acceleration is unclear) * acceleration: fullaccel then noaccel * color bits: highest first * pixel type: rgba then colorindex (for fullaccel formats it seems this takes precedence over color bits) * alpha bits: lowest first * aux buffers: highest first (relative ordering with alpha bits uncertain) * depth: highest first * stencil: highest first * accum bits: lowest first * double buffer: single buffer then double * swap method: undefined then copy
Each specified attribute (at least the ones I tried: color bits, alpha, depth, stencil) re-sorts the list with *lowest* values for that attribute first, filtering out values that don't meet the minimum requirement, but keeps relative order otherwise. For multiple specified attributes the attribute precedence order mentioned above seems to be used. Also if any attribute is specified all swap_copy formats are removed.
Intel -----
The nil order is not the same as the id order. The nil order is used as the basis for all results: specifying attributes filters out pixel formats from that nil order, but never re-sorts the list.
I couldn't make much sense of either the id or nil orders.