PDA

View Full Version : The point of EGLConfig?



cheery
11-17-2012, 06:08 PM
In every graphics context library there's a list of configs and I have to pick one. Then this config is spread along surface, context, and whatever.

Why opengl context needs to be configured for certain config and it can't pick the config from the read/draw surfaces? And why are we still required to pick from the fixed list of configs? The graphics cards do not seem to care because they usually have about any sensible combination of configs, so why does the developer need to care?

Is an inflexible configuration management some sort of legacy in opengl? If it is, couldn't we get rid of it?

oddhack
12-12-2012, 10:40 AM
In every graphics context library there's a list of configs and I have to pick one. Then this config is spread along surface, context, and whatever.

Why opengl context needs to be configured for certain config and it can't pick the config from the read/draw surfaces? And why are we still required to pick from the fixed list of configs? The graphics cards do not seem to care because they usually have about any sensible combination of configs, so why does the developer need to care?

Is an inflexible configuration management some sort of legacy in opengl? If it is, couldn't we get rid of it?

It's partly a legacy issue and partly that there are still restrictions of displayable windows to a subset of the formats the graphics card can support - you may be able to have RGBA32F or RGBA4444 renderbuffer attachments for offscreen rendering, but that doesn't mean you can necessarily have an X11 (GDI, etc.) window in that format when the framebuffer is configured as RGB888, for example.

As window systems based on composition become the norm, this restriction starts to look sillier, since there's always a copy operation involved in SwapBuffers in such systems. We are thinking about different approaches going forward but it will be some time until that might appear as formal specifications.