这些方案比较清晰地描述了更适合使用 SVG 的情况、更适合使用 Canvas 的情况，以及其他介于这之间的情况。它们描述了每种技术的优缺点，以便开发人员可以了解相应技术的行为并针对其应用程序做出好的选择。

从性能方面选择

有时存在一些外部影响，要求独立于（或几乎独立于）功能选择技术。有关使用 Canvas 或 SVG 的问题，存在两个主要区别。

有时开发人员的知识、技能组合和现有资产会对技术的选择起到重大作用。如果开发人员具备低级别图形 API 方面的深层知识，但在 Web 技术方面知识有限，则很可能会选择 Canvas 技术。

另外，性能对于高流量的网站来说是绝对关键的。可以对这两种技术的性能特征加以比较。这可能会要求开发 Canvas 没有附带的辅助功能、自定义样式以及更粒度化的用户交互功能。虽然 Canvas 通常被视为具有高性能，但是并不意味着它就是明显的选择。下图显示了 SVG 对象和 Canvas 对象之间在呈现时间上的差异。

一般情况下，随着屏幕大小的增大，画布将开始降级，因为需要绘制更多的像素。随着屏幕上的对象数目增多，SVG 将开始降级，因为我们正不断将这些对象添加到 DOM 中。这些度量不一定准确，以下方面的不同一定会引起变化：实现和平台、是否使用完全硬件加速的图形，以及 JavaScript 引擎的速度。

高保真度的复杂矢量文档

高保真度的复杂矢量文档已经成为并将继续成为 SVG 的最有效点，原因主要有两个。存在足够多的极为详细的文档，包括由 CAD 程序生成的那些文档，针对这些文档，SVG 的scalable部分提供了独立文档形式或嵌入网页中的文档形式的详细视图。通过该技术还可以进行高保真打印。SVG 的声明性性质向工具、客户端或服务器端提供从数据库生成形状的能力。 最后，我们看到了政府机构的发展，因工程图（为了专利）或工业图（为了城市规划目的）缘故从建议支持转变为对 SVG 的必需支持。这种转变还将继续，因为对于公众使用的电子文档（如下），政府部门越来越不是只喜欢一家供应商：

以下各图显示了前一方案中可以保留的详细信息示例。第一个图像显示可以在测试驱动网站上找到的网页快照。它包含呼吸系统图和元素周期表。

第二个图像显示同一张图放大 1000% 后的效果

尽管考虑到观察大的示意图的有用性，但在需要细化到细节处时或者出于工程目的需要打印整个示意图时，具有可缩放性的S将变得足够清晰和有价值。出于这些原因，我们将高保真度的复杂矢量文档放在谱表的远端，接近 SVG，如下图中所示。

这些文档也可以受益于交互性，这是 SVG 使这些方案最适合于保留图形模式的第二方面。

增强的 Web 图形 SVG 作为图像格式

SVG 另外还常用于简单图像，无论是应用程序还是网页中的图像，大图像还是小图像。由于 SVG 要加载到 DOM 中，或者创建图像前至少要进行解析，所以性能会稍微有所下降，但相比于呈现网页的成本（大约几毫秒），这种下降是极其微小。

在文件大小方面（为了评估网络流量的目的），下面演示的两个图像是一样的，只差了 1K（SVG 稍微大点，没有压缩）。

与以前一样，因为 SVG 作为图像格式是可缩放的，所以如果开发人员想要以更大的比例使用该图像，或者用户使用高 DPI的屏幕，则可移植网络图形 (PNG) 要么会变得异常，要么需要更大形式的文件来实现保真。

SVG 因此可以充当非常好的图像替换格式，甚至对网页上最简单的图像也是如此。静态 WebApp/网页图像因此落在谱表的 SVG 端。

像素操作

在谱表的另一端，当使用 Canvas 时可以获得快速的绘图速度，且不需要保留相应信息。存在若干种最适合于 <canvas> 的实时数据方案。使用光线跟踪在像平面上通过像素跟踪光线路径并模拟其与虚拟对象相遇的效果，可以水化图像。 下图显示了这种模拟。

需要很多计算，因此速度依赖于浏览器中的 JavaScript 引擎速度。然而尽管大多数情况下本地代码无可置疑要更快一些，但是随着 JavaScript 引擎逐渐成熟，我们开始看到在像程序集和 C++ 这样的时期内这种差距在缩小。

光线跟踪（通常在 Web 上的背景中完成）获得的效果甚为广泛。范围从创建许多不同的视觉效果（包括根据其他简单矢量图形创建逼真的图像）到应用照片过滤器以去除红眼。

因为 Canvas API 允许开发人员读写像素，所以这里唯一的限制是速度和想象力。上一个示例由 Adam Burmister 提供并且位于上。 在此示例中，可通过大量的库来实现创建最终图像所需的计算，但主结束函数是

fillRect

。

JavaScript