> I guess I’m a tiny bit surprised that the browsers are de-allocating and re-allocating memory for the re-render of the text box elements, since they don’t cha

> I guess I’m a tiny bit surprised that the browsers are de-allocating and re-allocating memory for the re-render of the text box elements, since they don’t change size. Presumably this would be texture memory? Does anyone here know precisely what’s happening there, and whether a render-to-texture won’t work for some reason? Is it normal for browsers to allocate memory for all element repaints, or is this something unique to text typing or font handling? It highly depends on the browser and the specific painting backend in use. With a traditional CPU painting backend, browsers typically render at tile granularity, and tiles shuffle in and out of a global pool for repaints. That is, when the browser goes to repaint content, the painter grabs a tile from a shared pool, renders the new content into it, and then hands it off the compositor, which swaps the tile buffer and places the old buffer into a pool. This means that the GPU memory access patterns are somewhat irregular. If the GPU is being used for painting, as for example in Skia-GL/Ganesh, then there are all sorts of caches and allocators in use by the backend. Typically, these systems try to avoid allocation as much as possible by aggressively reusing buffers. Allocating every frame is generally bad. But it can be hard to avoid, especially with immediate-mode APIs like Skia. (I would expect that WebRender could be better here long-term, though we probably have work to do as well.)