Html 是否有任何理由在 2D 游戏/应用程序中使用 WebGL 而不是 2D Canvas？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21603350/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is there any reason for using WebGL instead of 2D Canvas for 2D games/apps?
提问by Ali Shakiba
Is there any reason, except performance, for using WebGL instead of 2D-Canvas for 2Dgames/apps?
除了性能之外，是否有任何理由为2D游戏/应用程序使用 WebGL 而不是 2D-Canvas ？
In other word what 2D functionalities are offered by WebGL which are not possible to achieve easily with 2D-Canvas?
换句话说，WebGL 提供了哪些 2D 功能无法通过 2D-Canvas 轻松实现？
回答by Abstract Algorithm
Looking at this question from another side:
how does a developer choose one technology over another?
从另一个角度看这个问题：
开发人员如何选择一种技术而不是另一种？
- integrates better in their already built system
- is easier to use
- is faster
- has more capabilities or better suits their needs
- cost
- more platfrom-independant
- 更好地集成到他们已经构建的系统中
- 更容易使用
- 是比较快的
- 有更多的能力或更适合他们的需求
- 成本
- 更独立于平台
So I'll discuss the differences between canvas and webGL APIs regarding these qualities.
因此，我将讨论 canvas 和 webGL API 之间关于这些特性的差异。
Both canvas and webGL are JavaScript APIs. They are pretty much the same regarding integration (binding). They are both supported by a number of libraries that could speed up your coding. Different libraries give you different ways to organize your code, so library choice dictates how your drawing APIs are structured, but it's still pretty much the same thing (how the rest of the code binds together with it). If you use library, the ease of writing code depends on the library itself.
canvas 和 webGL 都是 JavaScript API。它们在集成（绑定）方面几乎相同。它们都得到了许多可以加快编码速度的库的支持。不同的库为您提供了不同的方式来组织您的代码，因此库的选择决定了您的绘图 API 的结构方式，但它仍然几乎相同（其余代码如何与其绑定在一起）。如果使用库，编写代码的难易程度取决于库本身。
If you write code from zero, the canvas API is much easier to learn and understand. It requires minimal math knowledge, and development is fast and straightforward.
如果您从零开始编写代码，canvas API 会更容易学习和理解。它需要最少的数学知识，并且开发快速而直接。
Working with the WebGL API requires strong math skills and a full understanding of the rendering pipeline. People with these skills are harder to find, production is slower (due to the size and complexity of such a code base), and therefore it costs more.
使用 WebGL API 需要强大的数学技能和对渲染管道的充分理解。拥有这些技能的人更难找到，生产速度更慢（由于此类代码库的规模和复杂性），因此成本更高。
WebGL is faster and it has more capabilities. No doubt about that. It's a native 3D API that gives you full access to the rendering pipeline, code and effects are executed faster and are more 'tweakable'. With webGL there really is no limit.
WebGL 速度更快，功能更多。毫无疑问。它是一种原生 3D API，可让您完全访问渲染管道、代码和效果的执行速度更快且更“可调整”。使用 webGL 真的没有限制。
Both canvas and webGL are html5 goodies. Usually the devices that support one will support and the other.
canvas 和 webGL 都是 html5 的好东西。通常支持一个的设备会支持另一个。
So, to sum up:
所以，总结一下：
- merging the drawing API code and the rest (integration): similar
- ease of use:
- (with library) canvas = webGL
- (from scratch) webGL << canvas
- speed: webGL > canvas
- capabilities: webGL > canvas
- cost: webGL is much more expensive
- platform: very similar
- 合并绘图 API 代码和其余部分（集成）：类似
- 便于使用：
- （带库）画布 = webGL
- （从头开始）webGL << 画布
- 速度：webGL > 画布
- 功能：webGL > 画布
- 成本：webGL 要贵得多
- 平台：非常相似
Hope this helps.
希望这可以帮助。
P. S. Open for discussion.
PS开放讨论。
回答by Prabindh
The biggest advantage is the programmability of the pipeline, and the performance. For example, say you are drawing 2 boxes one above other and one is hidden, some GL implementations have scope for discarding the hidden box.
最大的优势是流水线的可编程性和性能。例如，假设您正在绘制 2 个盒子，一个在另一个上面，一个是隐藏的，一些 GL 实现有丢弃隐藏框的范围。
As for comparisons, Since there is no quick way of creating a table here, I just uploaded a picture of the comparison table below. Added Three.js for completeness only.
至于对比，由于这里没有快速建表的方法，我只上传了下面对比表的图片。添加 Three.js 只是为了完整性。
回答by emackey
What 2D capability does WebGL offer that 2D canvas does not? The biggest one IMHO is the programmable fragment shaders on the graphics hardware. For example, in WebGL, one can implement Conway's Game of Life in a shader on your 3D hardware:
WebGL 提供哪些 2D 功能而 2D 画布没有？恕我直言，最大的一个是图形硬件上的可编程片段着色器。例如，在 WebGL 中，您可以在 3D 硬件上的着色器中实现 Conway's Game of Life：
http://glslsandbox.com/e#207.3
http://glslsandbox.com/e#207.3
This kind of 2D display would only run on the CPU, not the GPU, with a 2D canvas. All of the computations would be implemented in JavaScript, and would not be as parallel as the GPU even with the help of web workers. This is just one example of course, all kinds of interesting 2D effects can be implemented with shaders.
这种 2D 显示只能在带有 2D 画布的 CPU 上运行，而不是在 GPU 上运行。所有计算都将在 JavaScript 中实现，即使在网络工作者的帮助下，也不会像 GPU 那样并行。这当然只是一个例子，各种有趣的 2D 效果都可以通过着色器实现。
回答by 16807
Speaking from experience on my own applications, graphics shaders have been the one and only reason I've required support for WebGL. Ease of use has little bearing for me since both frameworks can be abstracted away with three.js. Assuming I don't need shaders, I allow use of either framework to maximize browser/machine support.
根据我自己的应用程序的经验，图形着色器是我需要支持 WebGL 的一个也是唯一的原因。易用性对我来说意义不大，因为这两个框架都可以用three.js 抽象出来。假设我不需要着色器，我允许使用任一框架来最大化浏览器/机器支持。
回答by Xk0nSid
Well, performance would be the one of the biggest reasons because when you are coding a game, it has to be fast. But there are a couple of other reasons for which you might want to choose WebGL over canvas. It offers the possibility to coding shaders, lighting and zooming, which is important if you are doing a commercial game app. Also canvas gets laggy after 50 sprites or so.
好吧，性能将是最大的原因之一，因为当您编写游戏时，它必须很快。但是还有其他一些原因，您可能希望在画布上选择 WebGL。它提供了对着色器、照明和缩放进行编码的可能性，如果您正在开发商业游戏应用程序，这很重要。在 50 个左右的精灵之后，画布也会变得迟钝。
回答by GameAlchemist
There's nothing you can do with Canvas you can't do with webGL : the canvas allows to crush the bytes with get/putImageData, and you might draw lines, circles, ... programmatically with webGL.
But if you're seeking to do quite some drawings, and also some effects at 60 fps, the performance gap is so high that it just won't be possible with canvas, when it will run ok in webGL. Performance is a root feature.
Canvas 没有什么是 webGL 不能做的：canvas 允许使用 get/putImageData 粉碎字节，并且您可以使用 webGL 以编程方式绘制线条、圆圈等。
但是，如果您正在寻求以 60 fps 进行相当多的绘图，以及一些效果，那么性能差距非常大，以至于画布无法实现，而在 webGL 中它可以正常运行。性能是一个根本特征。
Yet webGL is quite complicated to program : see if canvas is good enough for you or seek a library that will ease the pain...
Other drawback : it doesn't work on IE (but what does ?), and on some mobiles.
See here for compatibility : http://caniuse.com/webgl
然而，webGL 的编程非常复杂：看看 canvas 是否对你来说足够好，或者寻找一个可以减轻痛苦的库......
其他缺点：它在 IE 上不起作用（但是什么？），以及在某些手机上。
请参阅此处了解兼容性：http: //caniuse.com/webgl
回答by starmole
As you specifically want some classic 2d things that don't work well with canvas:
由于您特别想要一些不适用于画布的经典 2d 内容：
- color transforms (like blinking a sprite)
- repeating bitmap fills
- tiling maps under rotation (under canvas some implementations will create seams)
- deep layering (very implementation dependent)
- multiplicative or additive blending
- 颜色变换（如闪烁精灵）
- 重复位图填充
- 在旋转下平铺地图（在画布下一些实现会创建接缝）
- 深层（非常依赖于实现）
- 乘法或加法混合
... but of course you have pixel access, so you can do really anything, including the above, manually. But that can be really, really slow. You could emscripten Mesa openGl to render to canvas in theory.
...但当然您可以访问像素，因此您可以手动执行任何操作，包括上述操作。但这可能真的非常慢。理论上，您可以编写 Mesa openGl 以渲染到画布。
Another big reason to use webGL would be that the result is very easy to port to anywhere else. Which also makes the skill more valuable.
使用 webGL 的另一个重要原因是结果很容易移植到其他任何地方。这也使技能更有价值。
Reasons to use canvas are that it is still better supported and if you learn doing things pixel by pixel that is also a very valuable lesson.
使用 canvas 的原因是它仍然得到更好的支持，如果你逐个像素地学习做事，这也是非常宝贵的一课。
回答by MayorMonty
As WebGL is particularly new technology and HTML5 canvas is more established what you want to use depends on your users. If you think that your users will use mobile devices then I would suggest HTML5 canvas but if you want better 2D rendering I would use WebGL. So what you could do is if the use is on mobile render with HTML5 else if they are on a platform that supports WebGL.
由于 WebGL 是一项特别新的技术，而 HTML5 画布更加成熟，您想使用什么取决于您的用户。如果您认为您的用户将使用移动设备，那么我建议使用 HTML5 canvas，但如果您想要更好的 2D 渲染，我会使用 WebGL。因此，您可以做的是，如果使用的是 HTML5 的移动渲染，如果它们位于支持 WebGL 的平台上。
For example:
例如：
if (window.WebGLRenderingContext) {
webGLcanvasApp()
} else if( /Android|webOS|iPhone|iPad|iPod|BlackBerry|IEMobile|Opera Mini/i.test(navigator.userAgent) ) {
html5CanvasAppFMobile()
} else {
html5CanvasApp()
}
Sources:
Proper way to detect WebGL support?
What is the best way to detect a mobile device in jQuery?
回答by user185953
WebGL is unusable without a GPU.
This hardware dependency is not a big problem because most systems have GPUs, but if GPU or CPU architectures ever evolve, preserving webgl content by emulation may be challenging. Running it on old (virtualized) computers is problematic.
如果没有 GPU，WebGL 将无法使用。
这种硬件依赖性不是一个大问题，因为大多数系统都有 GPU，但如果 GPU 或 CPU 架构不断发展，通过仿真保留 webgl 内容可能具有挑战性。在旧的（虚拟化的）计算机上运行它是有问题的。
But "Canvas vs WebGL" does not have to be a binary choice. I actually prefer using webgl for effects, but doing the rest in canvas. When I run it in a VM, it still works nicely and fast, just without the effects.
但是“Canvas vs WebGL”不一定是二元选择。我实际上更喜欢使用 webgl 来制作效果，但在画布中完成其余的工作。当我在 VM 中运行它时，它仍然可以很好地快速运行，只是没有影响。
