代码拉取完成,页面将自动刷新
同步操作将从 OpenHarmony/third_party_opengles 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
<html>
<head>
<title>Promoting OpenGL Extensions</title>
</head>
<body>
<h1>Promoting OpenGL Extensions</h1>
<p> <i>Promoting</i> an extension refers to moving it from single-vendor
to multi-vendor or ARB-approved status, usually by changing the vendor
tag attached to the extension name string, enumerants and API entry
points. This is sometimes done when an extension is successful and more
licensees want to support it. This document describes the steps to
follow when promoting an extension.
<h3>Is Promotion Required?</h3>
<p> Changing the names creates a significant burden for ISVs supporting
the existing extension. It should not be done gratuitously; if the
existing interface is sufficient, there's no inherent reason an
implementation shipped by one vendor cannot advertise and support an
extension using another vendor's prefix.
<p> If you do this, make <b>certain</b> that the original vendor agrees
to freeze the definition of the extension, and that what you ship is
identical in behavior to what the original vendor is shipping. Shipping
what appears to be the "same" extension while implementing different
behavior on multiple platforms is a great disservice to ISVs trying to
use extensions, and to OpenGL in general.
<p> <b>Do not</b>, under any circumstances, ship an extension defined by
another vendor without first clearing it with that vendor.
<h3>Promoting Without Changes in Behavior</h3>
<p> If you nevertheless want to promote an extension from
vendor-specific to e.g. <tt>EXT</tt> status, without changing the
behavior or definition of that extension, then advertise and export
<b>both</b> the old and the new forms of the extension for maximum
backwards compatibility. This means that:
<ul>
<li>Both extensions strings should be included in the
<tt>GL_EXTENSIONS</tt> string query (or the corresponding
WGL/GLX query, if it extends those APIs).
<li>All enumerants should exist in both
<tt>GL_<i>VENDOR</i>_ENUM_NAME</tt> and
<tt>GL_EXT_ENUM_NAME</tt> forms, with the same values.
<li>All entry points should exist in both
<b>glExtensionName<i>Vendor</i></b> and
<b>glExtensionNameEXT</b> forms, resolving to the same code.
<li>For an extension supported under GLX, the same GLX protocol
should be generated no matter whether the vendor or <tt>EXT</tt>
version of the extension is called.
</ul>
<h3>Promoting With Changes in Behavior</h3>
<p> If you are promoting an extension while changing its definition or
behavior, <b>do not</b> treat it as identical to the old extension. This
means that:
<ul>
<li>Any new <tt>EXT</tt> enumerants which differ in definition from
the original <tt><i>VENDOR</i></tt> enumerants should be assigned new
values, and those values registered with SGI.
<li>All new <b>EXT</b> entry points should resolve to different code
in the GL client library than the original <b><i>Vendor</i></b>
extension entry points.
<li>For an extension supported under GLX, different GLX protocol
requests should be generated for the two extensions, so
they can be distinguished on the server side.
</ul>
<p> None of this should be taken to indicate that code cannot be shared
between implementations of the old and new extensions; simply that the
implementation must be able to distinguish whether the old or new form
is being called, since they are de facto different extensions despite
sharing similar purposes.
<hr>
<p> Last modified April 5, 1999 Jon Leech
</body>
</html>
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。