On Thu Mar 28 17:02:44 2024 +0000, Rémi Bernon wrote:
Sorry for the late feedback. Ofc there's a couple of comments here and there but IMO this looks quite nice already. Then let's explore some options to make it even better:
- What about moving it even further to the PE side? Keeping only
p_get_pixel_formats as a unix call, and pre-allocating a large-enough array to hold the pixel formats (or making two calls if it's not large enough), which could even be cached in some of the glReserved1 thread data - with the HDC to invalidate the cache when necessary. 2) Have you checked how these functions behave on Windows? Are they very different across drivers and hardware or can we find a pixels format subset that we could simply fake? How useful / likely is it to have some exotic formats exposed and used by applications?
Thanks for the feedback!
1. Sure, I can experiment more in this direction. With a move towards the PE side, we would we still want to allow drivers to override the behavior (at least for now) and fall back to the existing GetPixelFormatAttrib*/ChoosePixelFormatARB unix calls, right?
Concerning per-HDC caching, is this to support the possibility of different drivers (e.g., normal vs offscreen) in the same process (because otherwise the pixel format data is constant)? Were you thinking about something along the lines of glReserved[2] = <format array ptr>, glReserved[4] = <num formats>, glReserved[4] = <hdc associated with format array> ?
2. Not yet, but I plan to (for now I am just following the glx+tweaks rules). I have a small program that allows me to exercise `wglChoosePixelFormatARB` and I would like to run it on a few different setups to see if I can infer anything from the results.