现代浏览器如何有效地进行平铺渲染(特别是在Direct2D中)?

bri*_*ght 6 browser gecko webkit tiles direct2d

这个问题与浏览器如何将整个页面呈现为平铺图像有关(而不是在页面中呈现图像.)我最感兴趣的是内存成本.

我的理解是,像Chrome这样的浏览器将布局整个页面,但在小方块中根据需要渲染它的部分.当用户滚动页面时,仅呈现不存在的图块.平铺生成通常发生在后台线程中,但此问题与线程无关.

所以问题是,这种方法的总内存使用量是多少?

我们假设屏幕是1024x768,并且图块是64x64像素.所以屏幕是16x12瓷砖.此外,我假设每个图块是每像素32位,Direct2D是渲染平台,Direct2D SwapChainPanel用于性能.

在给定的渲染周期中,可能只渲染总(16x12)个图块的一小部分.但是,这个数字可能不止一个.因此

  1. 在我看来,1024x768的临时位图最方便渲染当前无效的图块.
  2. 然后将有效部分复制到大小为64x64的实际图块位图上,以便在下一步和将来的渲染周期中使用.
  3. 要渲染的最终位图是通过blitting相应的tile来组成的,其中一些可能是由较早的渲染周期生成的,而另一些则是在此渲染周期中.最终的位图也是1024x768.

因此,除了图块之外,似乎还需要两个全屏尺寸(1024x768)的32bpp位图.

问题:

  1. 浏览器实际上是每像素使用32位还是更低?
  2. 是否需要上面的步骤(3),或者有没有方法直接渲染瓷砖而没有最终的位图?
  3. 是否有任何额外的主内存分配,我可能错过了(例如通过GPU)?

中间副本的数量是一个微妙的,需要仔细考虑,所以我真的很感激准确的答案.请不要猜测.

Lot*_*har 0

对于 Chrome,我认为它不是渲染引擎中的实现,而是前端浏览器中的实现。我使用 CEF 并使用 Awesomium 都使用 Chrome/Webkit/Blink。您只需传递一个位图来渲染数据,因此前端必须决定最佳策略。

我认为没有人会实现那么小的瓷砖。我认为它们类似于 256 x 宽度(除非宽度特别大)的条纹。