implement window surface

[Adam Jackson]

On Tuesday 17 May 2005 17:44, Brian Paul wrote:
> Jon Smirl wrote:
> > Don't I need to implement window surfaces in the fbdev EGL driver? In
> > other words the ability to create a surface that will draw to a
> > clipped rectangle on an existing screen surface.  Without clipped
> > surfaces how can you implement a non-composed Xserver?
>
> The eglCreateWindowSurface() function is designed to be used in
> conjunction with the native window system's windows (X window or Win32
> window, etc).  It takes a <NativeWindowType> parameter.  So you'd use
> the native window system API to manage the window (XMoveWindow,
> XResizeWindow, XMapWindow, etc).
>
> So in our X-less EGL environment we'd probably need to add all those
> sorts of functions.

Either that, or don't.  My mental model of Xegl was that all X rendering 
surfaces would be textures internally, and the server's default composition 
code (equivalent to X without xcompmgr) would apply them to quads that you 
draw into the screen surface.  That's exactly the existing model that Xglx 
uses, where offscreen buffers are composed into a GLX window as textured 
quads.

There's not really any native window type to do eglCreateWindowSurface on.  
You'd have to get that handle from somewhere, right?  If you're the server, 
who do you ask for that handle?

So no, I don't think we need to, or can, support EGL windows in the standalone 
case.  Or pixmaps for that matter.  In both cases you need to pass in a 
native handle, and if you're running standalone there's no native window 
system.  I think in our world everything is a pbuffer or a screen for now.

> Another option I've been considering is to develop a new OpenGL/Mesa
> extension that extends the glScissor feature to allow clipping against
> a list of rectangles, not just one.  This would be used to implement
> cliprects for window regions.  The DRI drivers already support this
> internally for window clipping so it shouldn't be too hard to implement.
>
> What do the XGL people think of that?

Sounds good to me.

Some Wine people have also expressed a desire for greater control over 
cliprects to get windowed Direct3D working right.  I think they were wanting 
the ability to read the active clip list out of the driver though, which may 
be orthogonal to extending glScissor.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dri-egl/attachments/20050518/5e748ee9/attachment.pgp