Any plans that EGL will be the standard for desktop context/windowing creation?
This would be great if they can adopt the same API for other desktop platforms, and at least, implement it on top of the existing platform-specific API (wgl, glX…etc.)
Any reason why not yet?
Thanks.
Because EGL cannot be implemented on top of WGL.
Understood. But any reason why it’s (or something similar) not adopted as the standard context management for the desktop platforms (regardless of how it’s implemented)?
This can have several big benefits:
But any reason why it’s (or something similar) not adopted as the standard context management for the desktop platforms (regardless of how it’s implemented)?
Who’s going to implement and maintain it? Khronos doesn’t have programmers. They don’t exactly have money. They can contract out little things, like conformance tests, but something like that what you’re talking about isn’t easily or cheaply done.
- No need to use GLEW/GLEE
How? It doesn’t magically make function pointers sprout into being. You’re going to have to load them, just like before. It’s not like EGL made function pointer loading obsolete in GL ES land.
The absolute best you can do is make a certain level of OpenGL the new minimum you get from linking to the new import library. But there will always be a minimum.
Also, that last part? It has nothing to do with EGL. EGL specifies how you create a context; the functions you load from a particular library are all up you something else.
- Lower-level hardware functionality can be exposed there, such as video memory queries, timers, synch objects…etc.
… what? EGL doesn’t expose any of that. And there’s nothing preventing OpenGL implementations from exposing those now.
Also, we already have sync objects and timers! If you’re going to ask for things, at least do the forum the common courtesy of learning about what is currently in OpenGL, so that you don’t waste time wanting something that already exists.
- Nice way to ask for full-scene anti-aliasing
And what’s not nice about the current way? I generally avoid using context creation for anti-aliasing entirely, as I prefer using multisampled renderbuffers and blitting. This also has the advantage of making that little thing where users can override anti-aliasing settings worthless.
Who’s going to implement and maintain it? Khronos doesn’t have programmers. They don’t exactly have money. They can contract out little things, like conformance tests, but something like that what you’re talking about isn’t easily or cheaply done.
IHV’s driver developer team. 
I’m just asking why there’s no similar specification for context creation/management for the desktop platforms.
Also, that last part? It has nothing to do with EGL. EGL specifies how you create a context; the functions you load from a particular library are all up you something else.
But it can make it possible to link to ICD driver bypassing the antique 100-year old OpenGL32.dll. And by doing so the function pointers are provided by a regularly updated GL client (say icdGLlib.lib) or through dglGetProcAddress. This means no need to have wrappers that loads the pointers on top of OpenGL32.dll.
… what? EGL doesn’t expose any of that. And there’s nothing preventing OpenGL implementations from exposing those now.
Good API design prevents this :). This way we can move existing “lower level” calls to the context domain. I suppose GL is a rendering API, why mix it with synch/timer-query/video-memory calls and even lower-level wishlist features.
And what’s not nice about the current way?
It looks like a hack.
Discussion of bypassing opengl32.dll entirely has been discussed by khronos (or was it nvidia?) if I’m not mistaken. It hasn’t happened yet and it seems unlikely.
I don’t see the connection with GLEW. GLEE is actually a dead project. You might want to look at http://www.opengl.org/wiki/OpenGL_Loading_Library
Anyway, there is always the need for GLEW or whatever. Your program runs and you can check for the GL version or extension and give the user a meaningful message.
I don’t know why WGL/GLX/AGL was invented. If you ask me it is bad design if the objective was to have a platform independent API. I am not against having EGL for desktop GL.
I am prolly going to get flamed, but oh well… it’s Monday. I am not happy with EGL. The sins that I have against EGL are (and someone please flame if I am mistaken):
[ul][li] The color buffer bit-depth heart-ache. The model of EGL is get your EGLConfig, but when you make an EGLSurface with a window, you pass that along. So… you need to make sure the color bit depths match up between the window and your config. Typically. Or if they do not match, an implementation might do the conversion for you. Either case smells bad. It should be that the window already determines with color bit depths.[] ditto for pbuffer surfaces (i.e. EGLSurface from a pixmap).[] When I read the spec, it looks like the color bit depths need to be specified and the same when making GL contexts. Also EGLSurfaces need to also be made knowing which API is going to draw to the surface[] No formal language for creating a GL context which does not have a default framebuffer. I suppose some funky implementations could support eglMakeCurrent with the back and front buffers being EGL_NO_SURFACE, but the spec does not say anything about this, as far as I see[] No mention/support for sharing context data across process boundaries. There might be an extension in the works. but that is a might be. Right now to share image data across process boundaries it is convoluted (and requires EGL and GL extensions): EGLImage from pixmap and texture from EGLImage… but you lose mipmap levels, etc.[] Making (desktop) OpenGL contexts(i.e. not GLES1 and not GLES2) is not very well fleshed out… especially when compared to wgl/glxCreateContextAttribs. [] eglGetProcAddress. Only fetches function pointers of those functions not in the API version. The ugly I can see here is the potentially convoluted logic needed to handle getting a newer GL version than requested but you wish to use some functions from that version that have been back ported as an extension without ARB suffixes (for example GL_ARB_seperate_shader_objects when targeting say DX9 class hardware).[/ul][/li]
So I am not happy with EGL at all.
Discussion of bypassing opengl32.dll entirely has been discussed by khronos (or was it nvidia?) if I’m not mistaken. It hasn’t happened yet and it seems unlikely.
Reference link to the discussion?