3

我有一个在画布上绘制 260 多个图的应用程序。将它们放在单个画布上的决定是出于速度考虑 - 对于各种任务（例如缩放和平移）来说，这种方式要快得多。即，在这种情况下，不能选择拆分为 260 个画布。

在 Opera、Firefox 和 IE 上一切正常。但是，当高度大于 ~8130 像素（宽度恒定 - 834 像素）时，Chrome 会停止显示画布。

即，我能够动态添加/删除图表（它们相互堆叠），一旦高度超过 8130 像素，Chrome 就会简单地“隐藏”画布。它保持响应并且没有抛出错误 - 可能是什么原因？

4

1 回答 1

5

尽管标准为画布指定了无符号长尺寸：

interface HTMLCanvasElement : HTMLElement {
           attribute unsigned long width;
           attribute unsigned long height;

来源：WhatWG/Canvas 元素

大多数浏览器似乎将大小限制为 8192（Safari 显然为 6826）。

无论如何（一般来说）-

如果您需要比这更大的画布尺寸，我会说您绝对应该重新考虑设计。画布很少需要比您在屏幕上实际看到的更大。将画布视为数据的视口，而不是数据的持有者。这就是大多数操作系统的工作方式（在低级别），因为这已被证明是几十年来最好的方法。

考虑带宽要求（不完全准确，因为这是基于实现及其优化 - 但为了指向我们正在处理的内容）：

使用 RGBA 缓冲区的 8192 x 8192 像素的画布大小消耗 256 MB 原始内存（取决于浏览器的实现，它可能是双倍的）。

更新@ 60Hz 和带宽最低为 15 GB/秒。此外，其他浏览器和系统内容也增加了这一点。如果将其用于典型的消费类计算机（而不是开发人员计算机），则很容易失去理论上的好处。

是的，您可以通过预渲染一个大区域并通过简单地将像素从该区域移动到可见区域来将其移动到视口中来获得速度 - 直到某个点和某个成本（内存是一个因素）。与更显着的低级环境相比，使用 JavaScript 移动“blitting source”会损失一些速度增益。

通常最好将数据保存为矢量格式（数组/类型化数组/对象）并通过检查边界来绘制可视部分，即。哪些数据将在视口中可见。您可以通过各种方式优化数据以快速访问它（例如参见四叉树）。

渲染矢量数据并不像人们想象的那么昂贵（如果“正确”完成），画布越小，清除它和重绘数据的速度就越快。

然而，主要技巧是对画布上已经存在的内容进行 blit（与从巨大的画布进行 blitting 效果相同）并且只更新新的间隙。

我的2美分..

于 2013-07-15T14:39:06.950 回答