4 ms·
The lowest bound would be the size of the texture the page is rendered into, no ? If you're on a 4k screen an uncompressed rgba pixmap is already 31MB... And th
by jcelerier 5y ago
The lowest bound would be the size of the texture the page is rendered into, no ? If you're on a 4k screen an uncompressed rgba pixmap is already 31MB... And that's really just the raw pixel storage which needs to be associated with your process
- kragen 5y agoYou don't have to render the whole page to a pixmap at once; it's very reasonable for a display-list representation of the page using a font atlas to be a tiny fraction of that size, maybe 8 bytes per character, and a GPU shader can render the RGBA pixmap from a spatially partitioned display list on demand. 2144 characters of text on my 1920×1080 display extrapolates to 17152 characters on a 4K display, which would be 140K of display-list data. 0.14 MB is a lot less than 31MB. (You need additional display-list items for things like the #ff6600 bar at the top and the #f6f6ef background, but those occupy insignificant space even compared to the 2144 characters. The Yahoo/Y-combinator logo and the arrows also add a little bit.) Of course #notallpages are mostly text, and many of them will require intermediate storage for large photos, <canvas>es, or screenshots of faked Tweets. If you're on a smaller computer you might render one scan line at a time from a display list consisting of strings rather than individual characters. Those 2144 characters are in 29 lines, so the display list might be under 3K, and a 400-pixel 1-bit-per-pixel scan line is 50 bytes. If you're generating PAL this way you have 64 μs to render each line, which is about 1000–6000 instructions on current microcontrollers, and you can maybe manage 450 color pixels, another 2K or so of raw pixel storage.
- jcelerier 5y ago> and a GPU shader can render the RGBA pixmap from a spatially partitioned display list on demand. ... but... the GPU shader will need a surface to render into, no ? do you know of any OS where asking for a 1000x1000 surface does not allocate space for that in normal, non-GPU RAM ? I believe that this uses RAM on any mainstream desktop OS
- kragen 5y agoThe GPU shader could in theory be rendering into a tile that gets squirted out to the screen by the RAMDACs and then reused, but I think you're right that in practice the GPU has at least one full-screen framebuffer, usually two or, dismayingly, three. Often the monitor has an additional two or three! I'm not sure it's fair to charge that framebuffer to the browser, though. The windowing system needs to use the same 31MB before you start the browser up, after all. I don't know the answer to your question about mainstream desktop OSes and space allocation for shaders for windows that aren't being displayed. Maybe someone who knows more than you or me can chime in.
- jcelerier 5y ago> The windowing system needs to use the same 31MB before you start the browser up, after all. every process needs its own surface for compositing though. If you open 200 4k windows you'll get 200*31MB, they aren't going to share the memory with the desktop one
- kragen 5y agoThat's definitely one way to do it, and now that you mention it I do know that there are definitely things that do it that way, but it might not be a good one. Windows that aren't visible don't need their output surface to be materialized, and introducing a compositing step after your 4k window renders adds an extra 11 gigabytes per second of memory bandwidth at 120fps, and probably a few precious milliseconds of latency. In the limit of inexpensive rendering — which alpha-blending a few thousand rects from a font atlas might approach — it doubles the battery drain needed to redraw the screen.