Name ANDROID_recordable Name Strings EGL_ANDROID_recordable Contributors Jamie Gennis Contact Jamie Gennis, Google Inc. (jgennis 'at' google.com) Status Complete Version Version 2, July 15, 2011 Number EGL Extension #51 Dependencies Requires EGL 1.0 This extension is written against the wording of the EGL 1.4 Specification Overview Android supports a number of different ANativeWindow implementations that can be used to create an EGLSurface. One implementation, which records the rendered image as a video each time eglSwapBuffers gets called, may have some device-specific restrictions. Because of this, some EGLConfigs may be incompatible with these ANativeWindows. This extension introduces a new boolean EGLConfig attribute that indicates whether the EGLConfig supports rendering to an ANativeWindow that records images to a video. New Types None. New Procedures and Functions None. New Tokens Accepted by the parameter of eglGetConfigAttrib and the parameter of eglChooseConfig: EGL_RECORDABLE_ANDROID 0x3142 Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors) Section 3.4, Configuration Management, add a row to Table 3.1. Attribute Type Notes ---------------------- ------- -------------------------- EGL_RECORDABLE_ANDROID boolean whether video recording is supported Section 3.4, Configuration Management, add a row to Table 3.4. Attribute Default Selection Sort Sort Criteria Order Priority ---------------------- ------------- --------- ----- -------- EGL_RECORDABLE_ANDROID EGL_DONT_CARE Exact None Section 3.4, Configuration Management, add a paragraph at the end of the subsection titled Other EGLConfig Attribute Descriptions. EGL_RECORDABLE_ANDROID is a boolean indicating whether the config may be used to create an EGLSurface from an ANativeWindow that is a video recorder as indicated by the NATIVE_WINDOW_IS_VIDEO_RECORDER query on the ANativeWindow. Section 3.4.1, Querying Configurations, change the last paragraph as follow EGLConfigs are not sorted with respect to the parameters EGL_BIND_TO_TEXTURE_RGB, EGL_BIND_TO_TEXTURE_RGBA, EGL_CONFORMANT, EGL_LEVEL, EGL_NATIVE_RENDERABLE, EGL_MAX_SWAP_INTERVAL, EGL_MIN_SWAP_INTERVAL, EGL_RENDERABLE_TYPE, EGL_SURFACE_TYPE, EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_RED_VALUE, EGL_TRANSPARENT_GREEN_VALUE, EGL_TRANSPARENT_BLUE_VALUE, and EGL_RECORDABLE_ANDROID. Issues 1. Should this functionality be exposed as a new attribute or as a bit in the EGL_SURFACE_TYPE bitfield? RESOLVED: It should be a new attribute. It does not make sense to use up a bit in the limit-size bitfield for a platform-specific extension. 2. How should the new attribute affect the sorting of EGLConfigs? RESOLVED: It should not affect sorting. Some implementations may not have any drawback associated with using a recordable EGLConfig. Such implementations should not have to double-up some of their configs to one sort earlier than . Implementations that do have drawbacks can use the existing caveat mechanism to report this drawback to the client. 3. How is this extension expected to be implemented? RESPONSE: There are two basic approaches to implementing this extension that were considered during its design. In both cases it is assumed that a color space conversion must be performed at some point because most video encoding formats use a YUV color space. The two approaches are distinguished by the point at which this color space conversion is performed. One approach involves performing the color space conversion as part of the eglSwapBuffers call before queuing the rendered image to the ANativeWindow. In this case, the VisualID of the EGLConfig would correspond to a YUV Android HAL pixel format from which the video encoder can read. The EGLConfig would likely have the EGL_SLOW_CONFIG caveat because using that config to render normal window contents would result in an RGB -> YUV color space conversion when rendering the frame as well as a YUV -> RGB conversion when compositing the window. The other approach involves performing the color space conversion in the video encoder. In this case, the VisualID of the EGLConfig would correspond to an RGB HAL pixel format from which the video encoder can read. The EGLConfig would likely not need to have any caveat set, as using this config for normal window rendering would not have any added cost. Revision History #2 (Jamie Gennis, July 15, 2011) - Added issue 3. #1 (Jamie Gennis, July 8, 2011) - Initial draft.