1 <html> 2 3 <head> 4 <title>Promoting OpenGL Extensions</title> 5 </head> 6 7 <body> 8 <h1>Promoting OpenGL Extensions</h1> 9 10 <p> <i>Promoting</i> an extension refers to moving it from single-vendor 11 to multi-vendor or ARB-approved status, usually by changing the vendor 12 tag attached to the extension name string, enumerants and API entry 13 points. This is sometimes done when an extension is successful and more 14 licensees want to support it. This document describes the steps to 15 follow when promoting an extension. 16 17 <h3>Is Promotion Required?</h3> 18 19 <p> Changing the names creates a significant burden for ISVs supporting 20 the existing extension. It should not be done gratuitously; if the 21 existing interface is sufficient, there's no inherent reason an 22 implementation shipped by one vendor cannot advertise and support an 23 extension using another vendor's prefix. 24 25 <p> If you do this, make <b>certain</b> that the original vendor agrees 26 to freeze the definition of the extension, and that what you ship is 27 identical in behavior to what the original vendor is shipping. Shipping 28 what appears to be the "same" extension while implementing different 29 behavior on multiple platforms is a great disservice to ISVs trying to 30 use extensions, and to OpenGL in general. 31 32 <p> <b>Do not</b>, under any circumstances, ship an extension defined by 33 another vendor without first clearing it with that vendor. 34 35 36 <h3>Promoting Without Changes in Behavior</h3> 37 38 <p> If you nevertheless want to promote an extension from 39 vendor-specific to e.g. <tt>EXT</tt> status, without changing the 40 behavior or definition of that extension, then advertise and export 41 <b>both</b> the old and the new forms of the extension for maximum 42 backwards compatibility. This means that: 43 44 <ul> 45 <li>Both extensions strings should be included in the 46 <tt>GL_EXTENSIONS</tt> string query (or the corresponding 47 WGL/GLX query, if it extends those APIs). 48 <li>All enumerants should exist in both 49 <tt>GL_<i>VENDOR</i>_ENUM_NAME</tt> and 50 <tt>GL_EXT_ENUM_NAME</tt> forms, with the same values. 51 <li>All entry points should exist in both 52 <b>glExtensionName<i>Vendor</i></b> and 53 <b>glExtensionNameEXT</b> forms, resolving to the same code. 54 <li>For an extension supported under GLX, the same GLX protocol 55 should be generated no matter whether the vendor or <tt>EXT</tt> 56 version of the extension is called. 57 </ul> 58 59 60 <h3>Promoting With Changes in Behavior</h3> 61 62 <p> If you are promoting an extension while changing its definition or 63 behavior, <b>do not</b> treat it as identical to the old extension. This 64 means that: 65 66 <ul> 67 <li>Any new <tt>EXT</tt> enumerants which differ in definition from 68 the original <tt><i>VENDOR</i></tt> enumerants should be assigned new 69 values, and those values registered with SGI. 70 <li>All new <b>EXT</b> entry points should resolve to different code 71 in the GL client library than the original <b><i>Vendor</i></b> 72 extension entry points. 73 <li>For an extension supported under GLX, different GLX protocol 74 requests should be generated for the two extensions, so 75 they can be distinguished on the server side. 76 </ul> 77 78 <p> None of this should be taken to indicate that code cannot be shared 79 between implementations of the old and new extensions; simply that the 80 implementation must be able to distinguish whether the old or new form 81 is being called, since they are de facto different extensions despite 82 sharing similar purposes. 83 84 <hr> 85 86 <p> Last modified April 5, 1999 Jon Leech 87 </body> 88 </html> 89