Native surface creation

Brian Paul brian.paul at tungstengraphics.com
Fri Mar 11 13:28:19 PST 2005


Adam Jackson wrote:
> On Friday 11 March 2005 15:52, Brian Paul wrote:
> 
>>Adam Jackson wrote:
>>
>>>Comments?  Has anyone seen this addressed in other GLES implementations?
>>
>>Not that I know of, suprisingly.
> 
> 
> Weird.
> 
> 
>>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).
> 
> 
> I think I like this approach.  I had thought down these lines but making a new 
> type for EGLScreen, rather than making a screen a type of surface.  I like 
> your way better though.  The relationship between Displays and Surfaces is 
> currently very easy to describe and shimming another layer in seems wrong.

There's still some middle ground to explore:

What's the relationship between an EGLDisplay and a graphics card 
which drives two or more displays?

If an EGLDisplay corresponds to the card, there needs to be a way to 
query how many displays/screens are available (and the possible modes 
for each).

If an EGLDisplay corresponds to each display/screen, that simplifies 
those issues, but causes other wrinkles.

I'm leaning toward the former.  It would allow allocating one EGL 
screen surface that could be scanned out across two (or more) 
displays.  This is where the business of screen surfaces being larger 
than the display resolution comes into play.

Something to think about.

-Brian


More information about the dri-egl mailing list