luca-piccioni
commented
7 years ago I understand that the pixel format selection could be a pain (actually it is), but I have to partially disagree. The reasons could be explained by the following points:
- wglChoosePixelFormat (or glXChooseFBConfig, or whatever) takes as parameter(s) the criteria(s) to be used for selecting the pixel format. Indeed the design time properties would be used all the same for selecting the most appropriate pixel format. (Or do you want to be forced to inherit from the rendering control?)
- wglChoosePixelFormat (or glXChooseFBConfig, or whatever) is considering only a subset of the available pixel format (mainly the window-renderable pixel formats, but not the pixel buffer formats or other non-color-renderable formats). The only way for supporting future/exotic pixel formats is the custom implementation of a filter function, which is is implemented here (DevicePixelFormatCollection.Choose)
- The design-time attributes you set on GLControl defines the minimum requirements you need to run the application. This mimic the behavior of the wglChoosePixelFormat method (or glXChooseFBConfig, or whatever), but without giving up the flexibility offered by a custom filtering method.
Probably it would be more useful to present the pixel format issue with:
- Your design-time properties values you want to use
- The list of the pixel formats available on you platform
In this way I can understand what's going on, and consequently find issues in my code.
GLControl has a bunch of design time properties that describe the needed pixel format. This was actually a hindrance to getting it working on my machine as the device did not accept the chosen pixel format and the control threw an exception.
I don't know that much about XWindows but is there an equivalent to the wgl ChoosePixelFormat function where the device chooses the pixel format rather than has it imposed on it? This would be more robust.