• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1Name
2
3    KHR_config_attribs
4
5Name Strings
6
7    EGL_KHR_config_attribs
8
9Contributors
10
11    Jon Leech
12
13Contacts
14
15    Jon Leech (jon 'at' alumni.caltech.edu)
16
17Notice
18
19    Copyright (c) 2006-2013 The Khronos Group Inc. Copyright terms at
20        http://www.khronos.org/registry/speccopyright.html
21
22Status
23
24    Complete
25
26Version
27
28    Version 5, April 5, 2007
29
30Number
31
32    EGL Extension #1
33
34Dependencies
35
36    Requires EGL 1.2
37
38    Some of the extended config attributes defined by this extension are
39    only relevant when specific client APIs are supported.
40
41    This extension is written against the wording of the EGL 1.2
42    Specification. It exists for backwards compatibility with
43    functionality introduced in EGL 1.3.
44
45Overview
46
47    This extension adds new EGL config attributes and attribute bits
48    that express limitations of configs on a per-API basis, including
49    whether client APIs created with respect to a config are expected to
50    pass conformance, and which optional OpenVG color space and alpha
51    mask format attributes are valid at surface creation time.
52
53New Types
54
55    None
56
57New Procedures and Functions
58
59    None
60
61New Tokens
62
63    New EGLConfig bitmask attribute name:
64
65        EGL_CONFORMANT_KHR                  0x3042
66
67    Valid bitfields in the EGL_SURFACE_TYPE bitmask attribute
68    of EGLConfig:
69
70        EGL_VG_COLORSPACE_LINEAR_BIT_KHR    0x0020
71        EGL_VG_ALPHA_FORMAT_PRE_BIT_KHR     0x0040
72
73Additions to Chapter 3 of the EGL 1.2 Specification (EGL Functions and Errors)
74
75    Add to table 3.1, "EGLConfig attributes":
76
77        Attribute           Type        Notes
78        ---------           ----        -----
79        EGL_CONFORMANT_KHR  bitmask     whether contexts created with
80                                        this config are conformant
81
82    Add to table 3.2, "Types of surfaces supported by an EGLConfig":
83
84        EGL Token Name                  Description
85        --------------                  -----------
86        EGL_VG_COLORSPACE_LINEAR_BIT_KHR EGLConfig supports OpenVG rendering
87                                        in linear colorspace
88        EGL_VG_ALPHA_FORMAT_PRE_BIT_KHR EGLConfig supports OpenVG rendering
89                                        with premultiplied alpha
90
91    Add following the second paragraph of "Other EGLConfig Attribute
92    Descriptions" in section 3.4 on p. 16:
93
94       "If EGL_VG_COLORSPACE_LINEAR_BIT_KHR is set in EGL_SURFACE_TYPE,
95        then the EGL_COLORSPACE attribute may be set to
96        EGL_COLORSPACE_LINEAR when creating a window, pixmap, or pbuffer
97        surface (see section 3.5)."
98
99       "If EGL_VG_ALPHA_FORMAT_PRE_BIT_KHR is set in EGL_SURFACE_TYPE,
100        then the EGL_ALPHA_FORMAT attribute may be set to
101        EGL_ALPHA_FORMAT_PRE when creating a window, pixmap, or pbuffer
102        surface (see section 3.5)."
103
104    Add at the end of the fourth paragraph (description of
105    EGL_CONFIG_CAVEAT) on p. 17:
106
107       "... required OpenGL ES conformance tests (note that
108        EGL_NON_CONFORMANT_CONFIG is obsolete, and the same information
109        can be obtained from the EGL_CONFORMANT_KHR attribute on a
110        per-client-API basis, not just for OpenGL ES."
111
112       "EGL_CONFORMANT_KHR is a mask indicating if a client API context
113        created with respect to the corresponding EGLConfig will pass
114        the required conformance tests for that API. The valid bit
115        settings are the same as for EGL_RENDERABLE_TYPE, as defined in
116        table 3.3, but the presence or absence of each client API bit
117        determines whether the corresponding context will be conformant
118        or non-conformant(fn1)."
119
120       "(fn1) most EGLConfigs should be conformant for all supported
121        client APIs. Conformance requirements limit the number of
122        non-conformant configs that an implementation can define."
123
124    Add to the last paragraph of section 3.5.1 on p. 24 (describing
125    eglCreateWindowSurface):
126
127       "If <config> does not support the colorspace or alpha format
128        attributes specified in <attrib_list> (e.g. if EGL_COLORSPACE is
129        specified as EGL_COLORSPACE_LINEAR but the EGL_SURFACE_TYPE
130        attribute of <config> does not include
131        EGL_VG_COLORSPACE_LINEAR_BIT_KHR, or if EGL_ALPHA_FORMAT is
132        specified as EGL_ALPHA_FORMAT_PRE but EGL_SURFACE_TYPE does not
133        include EGL_VG_ALPHA_FORMAT_PRE_BIT_KHR), an EGL_BAD_MATCH error
134        is generated."
135
136    Add to the next-to-last paragraph of section 3.5.2 on p. 26
137    (describing eglCreatePbufferSurface):
138
139       "If <config> does not support the colorspace or alpha format
140        attributes specified in <attrib_list> (as defined for
141        eglCreateWindowSurface), an EGL_BAD_MATCH error is generated."
142
143    Add to the last paragraph of section 3.5.4 on p. 29 (describing
144    eglCreatePixmapSurface):
145
146       "If <config> does not support the colorspace or alpha format
147        attributes specified in <attrib_list> (as defined for
148        eglCreateWindowSurface), an EGL_BAD_MATCH error is generated."
149
150Issues
151
152    1) How should colorspace and alpha format restrictions be specified?
153       OpenVG implementations may not allow linear colorspace or
154       premultiplied alpha rendering to all configs they support.
155
156        RESOLVED: To maximize compatibility with EGL 1.3, we continue to
157        specify the desired colorspace and alpha format at surface
158        creation time. However, surface creation may fail if if the
159        specified colorspace or alpha format are not supported.
160
161        To allow apps to detect this situation, this extension adds
162        EGLConfig attributes specifying *if* linear colorspace and/or
163        premultiplied alpha formats are supported. If they are not
164        supported, surface creation with the corresponding attributes
165        set will fail with an EGL_BAD_MATCH error.
166
167    2) How should the colorspace and alpha format capabilities be
168       exposed in EGLConfigs?
169
170        RESOLVED: as bitfields of the existing EGL_SURFACE_TYPE bitmask
171        attribute.
172
173        A separate bitmask might be more orthogonal, but there are
174        plenty of unused bits in EGL_SURFACE_TYPE and this minimizes API
175        and programming complexity.
176
177    3) Are support for linear colorspace and and premultiplied alpha
178       formats orthogonal?
179
180        RESOLVED: Yes, according to the OpenVG Working Group. If they
181        were not orthogonal, we could not specify them as independent
182        bitfields.
183
184    4) Should information about conformance be specified on a
185       per-client-API basis?
186
187        RESOLVED: Yes. This is needed for conformance testing and cannot
188        be expressed by the EGL_CONFIG_CAVEAT attribute, which is OpenGL
189        ES-specific.
190
191    5) Should there also be a config attribute which specifies whether
192       EGL_RENDER_BUFFER will be respected?
193
194        UNRESOLVED: it would be consistent to add this attribute. but
195        it's not clear if there's a requirement for doing so yet.
196
197    6) Does this extension introduce a regression against EGL 1.2?
198
199        RESOLVED: Yes. This is unavoidable, since we're allowing failure
200        of surface creation that was required to succeed in the past.
201        However, implementations that could not support the required
202        colorspace or alpha mask format were effectively non-conformant
203        (e.g. broken) in any event. The new EGL_SURFACE_TYPE attributes
204        at least allow apps to know that their request will not be
205        satisfied.
206
207Dependencies on OpenGL ES
208
209    If OpenGL ES is not supported, the EGL_OPENGL_ES_BIT in the
210    EGL_CONFORMANT_KHR is irrelevant.
211
212Dependencies on OpenVG
213
214    If OpenVG is not supported, the EGL_OPENVG_BIT bit in
215    EGL_CONFORMANT_KHR, and the EGL_VG_COLORSPACE_LINEAR_BIT_KHR and
216    EGL_VG_ALPHA_FORMAT_PRE_BIT_KHR bits in EGL_SURFACE_TYPE, are
217    irrelevant.
218
219Revision History
220
221    Version 5, 2007/04/05 - add enum values corresponding to EGL 1.3
222        core features.
223    Version 4, 2006/10/24 - prefix the bitfield names with "VG" to
224        clarify that they only apply to OpenVG rendering to surfaces
225        (although the corresponding core EGL_COLORSPACE and
226        EGL_ALPHA_FORMAT attribute names do not currently include this
227        prefix). Use "KHR" suffix instead of "OES".
228    Version 3, 2006/10/15 - add new config attribute to express whether
229        configs are conformant on a per-API basis. Correct sRGB
230        terminology to linear (sRGB is the default, linear colorspace
231        rendering may not be supported). Change extension name
232        accordingly.
233    Version 2, 2006/09/26 - add _OES extension suffix to bitfield names.
234    Version 1, 2006/09/26 - first draft.
235