Different surface types

[Jon Smirl]

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?

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.

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.


-- 
Jon Smirl
jonsmirl at gmail.com