Different surface types

[Brian Paul]

Jon Smirl wrote:
> On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
> 
>>Jon Smirl wrote:
>>
>>>On 4/30/05, Brian Paul <brian.paul at tungstengraphics.com> wrote:
>>>
>>>
>>>>>Would the standalone world be simpler if there was just one kind of
>>>>>surface that migrated to VRAM if it is going to be used?
>>>>
>>>>I don't know.  But I like the idea of separate types/functions for
>>>>Pbuffers and screen surfaces because PBuffers have traditionally
>>>>always been known as off-screen surfaces and there's some pbuffer
>>>>operations (such as binding to textures) which don't seem appropriate
>>>>for screen surfaces.
>>>
>>>
>>>Why can't a screen surface be bound as a texture, for example a screen
>>>magnifier?
>>
>>I imagine that could be done with some hardware, but perhaps not with
>>others (for all sorts of reasons).
>>
>>If you want to explore how this could be accomodated with
>>EGL_MESA_screen_surface, feel free.  The existing EGL functions for
>>binding texture images to surfaces don't appear to to prevent this.  A
>>layered extension such as EGL_MESA_screen_texture could expose the
>>capability with little or no new API additions.
> 
> 
> Didn't OpenGL just add FrameBufferObjects as a generic object form
> instead of having all of the specialized objects?

Kind of.  The details of how the XGL system will be able to 
convert/bind application drawing surfaces as textures.  There's the 
business of the XGL server (a separate process) being able to 
name/address application drawing surfaces.  It may be that XGL might 
more easily be able to do the surface/texture tricks using the EGL API 
instead of GL_EXT_framebuffer_object.  That's a whole other discussion 
I'd rather not get into in this thread.


> Should the surface creation functions be changed to return a generic
> eglSurface type? Then you could try and use the surface in any
> function without casting. If the surface is not compatible you would
> get an error.

Are you asking for something new?

The eglCreateWindow/Pixmap/Pbuffer/ScreenSurface() functions all 
return EGLSurface handles.  A function like eglSwapBuffers takes an 
EGLSurface but no-ops if it's not a window surface.  Other 
surface-related functions could generate EGL_BAD_SURFACE if needed. 
I'd have to check the EGL spec to know if there's already instances of 
that.


> For example on PC class video hardware there is no difference between
> screen and pbuffers, or is there? Can pbuffers live in AGP space on
> some hardware? You might want to create a pbuffer with
> CreateScreenSurface to force it into VRAM instead of AGP.

I don't understand the last sentence.  Pbuffers aren't created with 
eglCreateScreenSurfaceMESA().  Do you mean surfaces in general?

-Brian