This question is related to how browsers display the entire page as tiled images (and not about rendering images on pages). I'm most interested in memory costs.
As far as I understand, a browser such as Chrome will fit the entire page, but display it in small square tiles if necessary. When the user scrolls the page, only those tiles that do not exist are displayed. Tile building usually takes place in a background thread, but this issue is not related to stream processing.
So the question is, what is the overall memory usage of this approach?
Suppose the screen is 1024x768 and the tile is 64x64 pixels. Thus, the screen has 16x12 tiles. Further, I assume that each fragment has 32 bits per pixel, that Direct2D is a rendering platform, and Direct2D SwapChainPanel used for performance.
During this rendering cycle, it is likely that only part of the total (16x12) fragments will be displayed. However, the number is likely to be more than one. therefore
- It seems to me that a bitmap with scratches of 1024x768 is most convenient to display the current invalid fragments.
- The actual parts are then copied to the actual 64x64 bitmap images for use in the next step and in future rendering cycles.
- The final bitmap image to be rendered is composed by mixing the appropriate fragments, some of which can be obtained as a result of the previous rendering cycle, and some in this rendering cycle. This final bitmap is also 1024x768.
Thus, it seems that in addition to tiles, two 32-bit full-screen raster images (1024x768) are needed.
Questions:
- Do browsers really use 32 bits per pixel or something lower?
- Is step (3) required above, or is there a way to render fragments directly without a final bitmap?
- Are there any additional allocations of main memory that I might have missed (for example, using the GPU)?
The number of intermediate copies is a subtlety that requires careful thought, so I would really appreciate the exact answers. No specs please.
source share