在Chrome 18中检测SwiftShader WebGL渲染器 [英] Detect SwiftShader WebGL renderer in Chrome 18

问题描述

我有一个2D HTML5游戏引擎( www.scirra.com )，我真的想检测WebGL是否将使用Chrome 18的"Swiftshader"软件渲染器进行渲染.如果是这样，我们将更倾向于使用普通的canvas 2D上下文，就像其他浏览器中那样.那里的人们都拥有低端的CPU，它们的CPU较弱，可以在进行软件渲染时将游戏转换成幻灯片放映，而且我认为在很多情况下2D canvas可以通过硬件加速.但是，WebGL上下文创建在Chrome中永远不会失败，并且没有明显的方法可以检测SwiftShader.

I have a 2D HTML5 game engine (www.scirra.com) and really want to detect if WebGL is going to render with Chrome 18's 'Swiftshader' software renderer. If so we would much prefer to fall back to the ordinary canvas 2D context, as happens in other browsers. The mass of people out there have low end machines with weak CPUs that turn the game in to a slideshow when software rendering, and I think in many cases the 2D canvas would have been hardware accelerated. However, the WebGL context creation never fails in Chrome and there is no obvious way to detect SwiftShader.

我尝试过的事情:

// Always returns "WebKit WebGL" regardless of SwiftShader
gl.getParameter(gl.RENDERER)

// Always returns "WebKit" regardless of SwiftShader
gl.getParameter(gl.VENDOR)

我可以尝试考虑最大纹理大小或其他MAX_ *属性之类的问题，但是我怎么知道即使使用SwiftShader，它们在机器之间也不会改变?而且由于我猜想SwiftShader的目的是模仿通用硬件，因此使用该方法仍可能会产生很多误报.

I could try taking in to account things like the maximum texture size or the other MAX_* properties, but how do I know they don't vary between machines even with SwiftShader? And since I guess SwiftShader aims to mimic common hardware, using that approach might still get a lot of false positives.

我不想编写启动性能测试，因为:

I don't want to write a startup performance test, because:

• 我们只是制造引擎，而不是制作任何特定的游戏，所以我不知道我们如何编写一个公平的测试，该测试在任何情况下都可以在任何性能配置中以高度准确的方式进行正常测试
• 好的测试可能需要一两秒钟才能完成运行，这可能会中断用户体验，或者使他们不得不观看一些正方形的移动或其他变化
• 这可能会带来新的复杂性，例如如果我们缓存结果，如果用户更新其驱动程序并解决问题该怎么办?

我不想在Chrome上完全禁用WebGL，因为硬件加速的WebGL性能可以是canvas 2D的两倍以上！如果我们这样做，那么每个人都会迷路.

I don't want to flat out disable WebGL on Chrome, because with hardware-accelerated WebGL performance can be over twice as fast as canvas 2D! If we did that, everyone loses.

我不想添加游戏中的开关或用户设置，因为有多少用户在乎呢?如果游戏运行缓慢，他们只会退出游戏，很可能不会寻找解决方案.这个游戏糟透了，我会去别的地方."我认为只有少数用户会打扰阅读说明，例如顺便说一句，如果这款游戏运行缓慢，请尝试将此设置更改为'canvas 2D'..."

I don't want to have to add in-game switches or a user setting, because how many users care about that? If the game is slow they'll just quit and most likely not search for a solution. "This game sucks, I'll go somewhere else." I think only a minority of users would bother reading instructions like "by the way, if this game is slow, try changing this setting to 'canvas 2D'..."

我目前的最佳猜测是使用 gl.getSupportedExtensions().我发现SwiftShader报告了以下扩展名:

My current best guess is to use gl.getSupportedExtensions(). I have found that SwiftShader reports the following extensions:

OES_texture_float,OES_standard_derivatives,WEBKIT_WEBGL_lose_context

...但是真实的硬件加速上下文报告:

...but a real hardware-accelerated context reports:

OES_texture_float,OES_standard_derivatives,WEBKIT_WEBGL_lose_context,WEBKIT_WEBGL_compressed_textures

请注意添加 WEBKIT_WEBGL_compressed_textures .一些快速研究表明，这一点可能会得到广泛支持，也可能不会得到广泛支持.参见

Note the addition of WEBKIT_WEBGL_compressed_textures. Some quick research indicates that this may or may not be widely supported. See this support table - both GL_EXT_texture_compression_s3tc and GL_ARB_texture_compression appear widely supported on desktop cards. Also the table only seems to list reasonably old models, so I could hazard a guess that all modern desktop graphics cards would support WEBKIT_WEBGL_compressed_textures... therefore my detection criteria for SwiftShader would be:

• Windows操作系统
• Google Chrome浏览器
• WebGL上下文不不支持 WEBKIT_WEBGL_compressed_textures
• 结果:回退到Canvas 2D

当然，如果SwiftShader将来增加了压缩纹理支持，这将再次中断.但是我看不到使用软件渲染器压缩纹理的优势！此外，如果有很多不支持 WEBKIT_WEBGL_compressed_textures 的实际工作视频卡，它将仍然会产生很多误报！！

Of course, if SwiftShader adds compressed texture support in future, this breaks again. But I can't see the advantage of compressed textures with a software renderer! Also, it will still get lots of false positives if there are many real working video cards out there that don't support WEBKIT_WEBGL_compressed_textures!

有没有更好的方法来检测SwiftShader?

Is there not a better way to detect SwiftShader?

推荐答案

您说您不想编写启动性能测试"，即同时使用2D和WebGL渲染一些帧并进行测量速度更快，然后再使用该选项-但我仍然认为这是最佳选择.

You say you don't want to write a "startup performance test" — that is, render a few frames using both 2D and WebGL and measure which is faster, then use that one — but I still think it is the best option.

优势:

• 选择在当前硬件上实际上更快的渲染器，而不考虑其明显的属性.

• Selects the renderer that is actually faster on the current hardware, regardless of its apparent attributes.

缺点/缺点:

• 您必须为两个渲染器加载资源，这可能会增加加载时间(但您会记住选择的内容，因此只能发生一次).
• 如果系统最初运行缓慢(例如由于寻呼)，则可能是错误的测量结果.
• 没有主动冷却的硬件(例如电话)可能会过热，并在以后一段时间降低性能.您无法直接测量这两种方法的热量输出.(如果您有很好的机会重新测量并重新选择渲染方法，例如在加载新关卡时使用静态屏幕，则可以这样做.)

解决您的特定问题:

• 由于您正在编写游戏引擎，因此必须为游戏开发人员提供一种方法，以指定要在测试中使用的示例内容.
• 一两秒钟并不是很多额外的加载时间，尤其是(如我所怀疑的)如果没有可靠的方式来区分渲染器的话.在测试过程中，无需使用户正在使用的画布元素可见.您可以呈现一个完全不相关的加载动画.

• Since you are writing a game engine, you will have to provide the game developer with a way to specify sample content to use in the test.
• A second or two isn't a whole lot of additional load time, especially if (as I suspect) there is no reliable way to discriminate renderers otherwise. There is no need to make the canvas elements you are using visible to the user during the test; you could present an entirely unrelated loading animation.

这篇关于在Chrome 18中检测SwiftShader WebGL渲染器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！