标题几乎解释了这一切。昨天我在浏览Stack时第一次听说OpenGL Loader Generator项目，我查看了它以调查它对GLEW的优势。在项目网站上，他们声明：
此加载程序生成系统用于创建OpenGL标头和 根据您的特定需求加载代码。而不是每一个 扩展和核心枚举器/功能都在一个大型标题中，你 只获得你真正想要的东西并要求。
虽然我理解这种方法肯定比GLEW更简洁，但我不明白这种方法如何改善编译时间，应用程序性能或与OpenGL驱动程序的交互。此外，似乎使用它的过程需要更多维护，因为每次需要使用额外的扩展时都必须重新生成扩展源。我在使用GLEW时没有注意到任何性能损失（与不使用它相比），所以我很好奇为什么这个项目的开发人员觉得他们有问题需要解决。我错过了什么吗？
答案 0 :(得分：13)
为了完全披露，我编写了OpenGL Loader Generator。
虽然我理解这种方法肯定比GLEW更简洁，但我不明白这种方法如何改善编译时间，应用程序性能或与OpenGL驱动程序的交互。
这是一个OpenGL函数加载库。使用"Function CPP"样式的内联转发函数的可能例外，它只是调用函数指针。就像GLEW一样。
两者之间唯一可能的性能差异在于加载这些功能所需的时间（即：初始化例程）。而且由于这是一个初始化函数，它的一次性能是无关紧要的，除非它显然很慢。
简而言之，提高“应用程序性能或与OpenGL驱动程序的交互”并不是工具的目的。它的存在是干净的标题，它只包含您打算使用的OpenGL部分。此外，它可以让您轻松使用GLEW或GLee风格的函数初始化，如您所见。
至于“编译时间”性能，我认为编译100KB标题比800KB标题更便宜。但由于GLEW和我的工具都不使用元编程或模板等高级C ++技术，因此任何编译时节省的成本都很低。
此外，似乎使用它的过程需要更多维护，因为每次需要使用额外的扩展时都必须重新生成扩展源。
这当然是使用该工具的一种方式。使用该工具的另一种方法是提前确定哪些扩展适合您并使用它们。
一般来说，当您编写真正的OpenGL应用程序时，您可以针对特定的OpenGL版本编写该代码。此版本由您希望支持的最低硬件决定。如果你想支持从过时的英特尔945“GPU”到AMD和NVIDIA最新高端产品的一切，你必须写反对GL 1.4（可能是2.1，如果你感觉真的勇敢并且愿意对英特尔驱动程序进行大量测试。如果你想支持更新的硬件，你可以根据你想给英特尔GPU提供多少支持来编写一个OpenGL 3.x版本的代码。
从那里，您可以决定要支持的更高版本的可选功能，或者只是硬件特定的功能。您有一个您打算使用的东西列表，因此您需要检查这些扩展并有条件地使用或不使用它。
这就是这个工具的用途：当你确定了一组特定的扩展和OpenGL版本时。如果您想要更灵活，您可以生成包含更多扩展名的标题，即使您不使用它们也是如此。或者你可以使用GLEW;我的工具是选项，而非要求。
该工具并不适合每个人。它适用于那些知道自己想要什么的人，他们希望标题不包含kilobytes of crap extensions that they will {{3 }}
它也适用于自动完成等。使用 clean 标头，您必须筛选远没有打算调用的垃圾。哦，它有助于阻止您不小心使用您忘记检查的扩展程序中的内容。因为它不在您的标题中，所以任何调用此类函数或使用这些枚举的尝试都将导致编译器错误。
这是有益的另一件事是易用性。只需看看never use。这部分是因为GLEW可以编译为静态或动态库。因此，您必须在代码中使用#define在它们之间切换（在Windows上）。那很糟糕。
使用生成器，您只需将标题和源标记在常规版本中即可。没有要构建或链接的库。只需要几个额外的标题和源文件。
这就是我编写工具的原因。
答案 1 :(得分：1)
我认为没有明显的性能提升，但您只需使用OpenGL函数声明获得更小的头文件/源文件。
GLEW / GLEE在库中有所有版本组合+扩展 - 这使得它非常大。例如，GLEW 1.7的头文件有834kb。
OpenGL Loader为所需的OpenGL版本制作自定义文件。它们要小得多（例如（核心opengl 4.2的大约120kb标题+ 130kb源文件）。这将编译得更快 GLEW库，当然它的输出代码更小。