Native surface creation

[Brian Paul]

Adam Jackson wrote:
> First of all, hello all, thanks for subscribing.  For people who don't have 
> copies of the spec handy, the EGL manual is available online at:
> 
> http://www.khronos.org/opengles/documentation/opengles1_1/gl_egl_ref_1_1_20041110/index.html
> 
> I've been thinking a bit about how to get surface creation handled properly.  
> The application I'm targeting with this is Xgl, an X server running directly 
> on a GL stack.  I would like to leverage the EGL API for this as much as 
> possible.  The first problem, of course, is setting up the framebuffer for 
> drawing.  It's important to not require X client headers for this, for two 
> reasons.  One, Xegl conceptually isn't an X client.  Two, someone might want 
> to write some other window system or native EGL app that doesn't rely on any 
> other existing window system.
> 
> The existing API is:
> 
> EGLSurface eglCreateWindowSurface(EGLDisplay display,
>                                   EGLconfig config,
>                                   NativeWindowType native_window,
>                                   EGLint const *attrib_list);
> 
> eglCreateWindowSurface expects the application to have already created a 
> window.  Native EGL applications don't have any way to create a window 
> because they are the window system and they haven't bootstrapped yet.  
> eglCreatePixmapSurface has a similar problem.
> 
> We could create a new token for the native_window or attrib_list parameters 
> that becomes a magic word for "create a new surface please" but I'm not sure 
> I like that idea.  Overloading native_window in particular seems like a bad 
> idea because NativeWindowType is opaque, and we could reasonably have 
> collisions between the EGL enum space and (say) the XID space.  Adding 
> attributes is relatively risk free since right now that parameter is unused 
> for window creation.
> 
> Alternatively we could create a new entrypoint:
> 
> EGLSurface eglSetupFramebufferXXX(EGLDisplay display,
>                                   EGLConfig config,
>                                   EGLint const *attrib_list);
> 
> I don't know that this is different enough from CreateWindowSurface to justify 
> another entrypoint, when we could just ignore the native_window arg.  It's 
> reasonable in either approach to add several new valid attributes to the 
> list: resolution, color depth, refresh rate, interlacing/doublescan, etc.
> 
> So much for the API.  On the implementation side, assume there's some bit in 
> the EGLDisplay that specifies what device we're operating on (I'll talk more 
> about this in another post), or else a handle to a low-level context or 
> dispatch table, or whatever.  For "native" surface creation we can just hand 
> this request down to the driver level for that EGLDisplay and the driver can 
> implement it however it likes, it's a black box as far as the EGL engine is 
> concerned.
> 
> All of this happens after we have a valid EGLDisplay, so we can check for this 
> extension using eglQueryString.
> 
> Comments?  Has anyone seen this addressed in other GLES implementations?

Not that I know of, suprisingly.


Anyway, I've been thinking about this too.  I think there's (at least) 
two separate aspects to framebuffer setup: memory allocation and 
actual display.

There's currently EGL window, pixmap and pbuffer surfaces.  I'd add a 
4th kind: screen surfaces.  A screen surface would be special in that 
the (front and/or back) color buffer(s) of the surface would be 
allocated/formatted such that they could be directly scanned out to 
the display (CRT/LCD/etc).

Next, there'd be a mechanism to specify the display's resolution, 
color depth, refresh rate, etc.

Finally, there'd be a function, such as eglShowSurfaceXXX(), that 
would would display the named surface on the CRT/LCD.  Note that the 
surface width/height wouldn't have to match the display's resolution- 
it could be larger.  There'd be another function to specify the 
translation/origin of the surface on the display.  This would be like 
the conventional X "virtual resolution" and would allow scrolling.

One could allocate a bunch of screen surfaces and display any one of 
them at a time with eglShowSurfaceXXX().

I started sketching out some code for this, but I'm not quite happy 
with it yet.

-Brian