1Name 2 3 KHR_vg_parent_image 4 5Name Strings 6 7 EGL_KHR_vg_parent_image 8 9Contributors 10 11 Ignacio Llamas 12 Gary King 13 Chris Wynn 14 15Contacts 16 17 Gary King, NVIDIA Corporation (gking 'at' nvidia.com) 18 19Notice 20 21 Copyright (c) 2006-2013 The Khronos Group Inc. Copyright terms at 22 http://www.khronos.org/registry/speccopyright.html 23 24Status 25 26 Complete. 27 Approved by the Khronos Board of Promoters on February 11, 2008. 28 29Version 30 31 Version 5, October 8, 2008 32 33Number 34 35 EGL Extension #4 36 37Dependencies 38 39 This extension requires EGL 1.2 and the EGL_KHR_image extension, 40 and an OpenVG implementation 41 42 This specification is written against the wording of the EGL Image 43 (EGL_KHR_image) specification. 44 45Overview 46 47 This extension provides a mechanism for creating EGLImage objects 48 from OpenVG VGImage API resources. For an overview of EGLImage 49 operation, please see the EGL_KHR_image specification. 50 51New Types 52 53 None 54 55New Procedures and Functions 56 57 None 58 59New Tokens 60 61 EGL_VG_PARENT_IMAGE_KHR 0x30BA 62 63 64Additions to the EGL Image (EGL_KHR_image) Specification: 65 66 Add the following to Table aaa (Legal values for CreateImageKHR 67 <target> parameter), Section 2.5.1 (EGLImage Specification) 68 69 +--------------------------+--------------------------------------------+ 70 | <target> | Notes | 71 +--------------------------+--------------------------------------------+ 72 | EGL_VG_PARENT_IMAGE_KHR | Used for OpenVG VGImage objects | 73 +--------------------------+--------------------------------------------+ 74 75 Insert the following text after paragraph 3 ("If <target> is 76 NATIVE_PIXMAP_KHR...") of Section 2.5.1 (EGLImage Specification): 77 78 "If <target> is EGL_VG_PARENT_IMAGE_KHR, <dpy> must be a valid EGLDisplay, 79 <ctx> must be a valid OpenVG API context on that display, and <buffer> 80 must be a handle of a VGImage object valid in the specified context, cast 81 into the type EGLClientBuffer. Furthermore, the specified VGImage 82 <buffer> must not be a child image (i.e. the value returned by 83 vgGetParent(<buffer>) must be <buffer>). If the specified VGImage 84 <buffer> has any child images (i.e., vgChildImage has been previously 85 called with the parent parameter set to <buffer>), all child images will 86 be treated as EGLImage siblings after CreateImageKHR returns. Any values 87 specified in <attr_list> are ignored." 88 89 Add the following errors to the end of the list in Section 2.5.1 (EGLImage 90 Specification): 91 92 " * If <target> is EGL_VG_PARENT_IMAGE_KHR, and <dpy> is not a 93 valid EGLDisplay, the error EGL_BAD_DISPLAY is generated. 94 95 * If <target> is EGL_VG_PARENT_IMAGE_KHR and <ctx> is not a 96 valid EGLContext, the error EGL_BAD_CONTEXT is generated. 97 98 * If <target> is EGL_VG_PARENT_IMAGE_KHR and <ctx> is not a valid 99 OpenVG context, the error EGL_BAD_MATCH is returned. 100 101 * If <target> is EGL_VG_PARENT_IMAGE_KHR and <buffer> is not a handle 102 to a VGImage object in the specified API context <ctx>, the error 103 EGL_BAD_PARAMETER is generated. 104 105 * If <target> is EGL_VG_PARENT_IMAGE_KHR, and the VGImage specified by 106 <buffer> is a child image (i.e., vgGetParent(<buffer>) returns 107 a different handle), the error EGL_BAD_ACCESS is generated." 108 109Issues 110 111 1. Should this specification allow the creation of EGLImages 112 from OpenVG child images? 113 114 RESOLVED: No. It is believed that properly addressing the 115 interaction of hardware restrictions (e.g., memory alignment), 116 arbitrary image subrectangles, scissor rectangles and viewport 117 rectangles may create an undue burden on implementers. In the 118 interest of providing a useful spec in a timely fashion, this 119 functionality has been disallowed, with the possibility of 120 providing it (if necessary) through a future layered extension. 121 122 This restriction is shared with eglCreatePbufferFromClientBuffer; 123 however, this specification allows EGL Images to be created 124 from VGImages which have child images, functionality not 125 previously available. 126 127Revision History 128 129#5 (Jon Leech, October 8, 2008) 130 - Updated status (approved as part of OpenKODE 1.0) 131#4 (Jon Leech, April 5, 2007) 132 - Assigned enumerant values 133 - Added OpenKODE 1.0 Provisional disclaimer 134#3 (December 14, 2006) 135 - Changed requirement to egl 1.2 to include EGLClientBuffer type. 136 - added error condition descriptions for <dpy> and <ctx> 137#2 (November 27, 2006) 138 - Changed OES token to KHR 139