EGL_MESA_screen_surface version 4

[Brian Paul]

Michel Danzer wrote:
> On Wed, 2005-03-23 at 08:19 -0700, Brian Paul wrote: 
> 
>>Issues
>>
>>    1. Should EGL_INTERLACE be a supported mode attribute?
> 
> 
> [...]
> 
> 
>>       Arguments for:
>>
>>	   An interlaced display can be of use without considering video
>>	   material.  Being able to query whether a screen is operating in
>>	   interlaced mode can be used by applications to control their
>>	   drawing.  For example: avoid drawing 1-pixel-wide horizontal lines
>>           if screen is interlaced. [B. Paul]
> 
> 
> Good point, I can agree to this.
> 
> 
> 
>>    8. Should eglQueryModeStringMESA() be included?  This function returns
>>       a human-readable string which corresponds to an EGLMode.
>>
>>       Arguments for:
>>
>>           A mode name such as "HDTV-720P" might mean more to users than
>>           "1280x720 at 60Hz" if the later were generated via code.
> 
> 
> I agree, but I think it should be made clear that the mode names are
> implementation specific, subject to change and don't have any meaning
> beyond being unique for each mode. Applications should never try to
> identify modes by name.

I'll strengthen the language for that.


>>    EGLSurface eglCreateScreenSurfaceMESA(EGLDisplay dpy, EGLConfig config,
>>                                          const EGLint *attrib_list)
>>
>>    Create a surface that can be displayed on a screen.  <attrib_list> is
>>    an array of token/value pairs terminated with EGL_NONE.  Valid tokens
>>    include:
>>
>>        Name              Description
>>        ----------------  --------------------------------
>>        EGL_WIDTH         desired surface width in pixels
>>        EGL_HEIGHT        desired surface height in pixels
>>
>>    Any other token will generate the error EGL_BAD_ATTRIBUTE.
> 
> 
> What will happen if either of these attributes is omitted?

Good question.  For eglCreatePbufferSurface(), the default width and 
height are zero.  Since there's no way to resize a Pbuffer surface, 
that seems sort of useless.  Oh well.  Is there any objection to 
simply doing the same thing for screen surfaces?

Actually, here's a scenario to consider.  Suppose one wants to change 
the screen's size in the EGL application.  Also suppose there's a 
hardware restriction such that only one screen surface can exist at a 
time (either for lack of memory or because of memory layout restrictions).

The basic idea is that the currently displayed screen surface must be 
deallocated before a new one can be created.  Can people cope with 
that?  Or should there be a function to resize an existing screen surface?

-Brian