tag:blogger.com,1999:blog-4535528758590979933.post4256870095409708990..comments2022-03-11T02:58:06.682-05:00Comments on Casually Defiant: The Eagle EGL loaderKristian Høgsberghttp://www.blogger.com/profile/01071042513787555957noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-4535528758590979933.post-92208529592622931102009-07-30T23:18:46.091-04:002009-07-30T23:18:46.091-04:00You could certainly suggest or write an EGL extens...You could certainly suggest or write an EGL extension that constructs an EGLSurface "from scratch" using the eglCreateWindowSurface() attrib_list to specify things like width, height etc. However, since neither EGL nor GLES is a window system, there is no mechanism for moving, resizing, restacking etc such a window, which is perhaps why such extensions have not caught on.<br /><br />Also note that the "NativeWindowType" does not necessarily have to be a single type. You could have a platform whose "NativeWindowType" is a union of several objects. For example eglCreateWindowSurface could accept a window object, a GEM buffer handle, an LCDscreen object, or an overlay object, etc, cast to EGLNativeWindowType. (you might need a new attribute to indicate what type of object you are passing unless each of those objects is distinguishable on your system).<br /><br />-AcornAcorn Pooleyhttp://www.rawbw.com/~acornnoreply@blogger.comtag:blogger.com,1999:blog-4535528758590979933.post-53112416709739674062009-07-20T16:58:42.714-04:002009-07-20T16:58:42.714-04:00@Jon: I understand that EGL has to integrate with ...@Jon: I understand that EGL has to integrate with whatever underlying display system, whether this is X or just a naked framebuffer. However, I don't agree with the half-hearted API entry points that EGL provides to this end.<br /><br />The entry points are clearly designed to make X integration easy; I can see how you can pass an X Display or and X Window directly to the constructors. However, that's the least interesting case. Any real embedded EGL stack will have custom/proprietary functions to create the resources that back the EGLDisplay and EGLSurface. Maybe I have to pass width, height and stride to an implementation specific constructor to create the EGLNativeWindowType, which I then pass straight to eglCreateWindowSurface(). If I have to call out to implementation specific code, wouldn't it be much easier if I could just create the EGLSurface directly from an implementation specific constructor? What are the lifetime rules for the native types? Do I destroy them after creating the EGLSurface, after destroying the EGLSurface or not at all? It would be a lot accomodating not to force an implementation to invent these native types.<br /><br />Ideally, the native part of the API should be described in an appendix as the recommended way of integrating with X and be optional. Creating EGLDisplay and EGLSurface directly from the implementation specific code should be the recommended way for all other implementations.<br /><br />As for the "braindead" comment, that wasn't targeted at the API designers but at the API. I know that may be a academic distinction as we all take pride in our work. However, it wasn't a personal attack, it was a way to vent over a problem with an important API that I have no way to influence.Kristian Høgsberghttps://www.blogger.com/profile/01071042513787555957noreply@blogger.comtag:blogger.com,1999:blog-4535528758590979933.post-47097332347796205362009-07-20T16:04:16.806-04:002009-07-20T16:04:16.806-04:00The reason you create EGL displays and window surf...The reason you create EGL displays and window surfaces from native resources is that EGL is explicitly designed to integrate Khronos APIs into an existing native window system where this association must be made. Nothing prevents an implementation from using EGL_DEFAULT_DISPLAY and defining some dummy handle for a native window type, however.<br /><br />Incidentally, calling people who design software you don't agree with "frickin' braindead" is a really, really, profoundly *bad* way to encourage them to do anything to help you out in the future.<br /><br />Jon LeechJon Leechnoreply@blogger.comtag:blogger.com,1999:blog-4535528758590979933.post-41471502022845061492009-07-08T17:53:01.342-04:002009-07-08T17:53:01.342-04:001) you had promised a GTK wayland backend in an ea...1) you had promised a GTK wayland backend in an earlier post :(<br /><br />2)Is there something that stops Wayland from working with the gallium3d based EGL (all drivers are going to use gallium in a few months)<br /><br />3)Congrats for the miniHoegsbers<br /><br />keep up the good work :-)Anonymousnoreply@blogger.com