The offscreen buffer used for doublebuffering typically varies between 1/2 Mb to 3Mb in size, depending on the display depth and size of the browser window. The viewmanager only uses the offscreen during painting as a scratch area for rendering to before copying forward to the onscreen window. We should investigate whether or not it is possible to use the memory allocated for double-buffering as a temporary buffer for operations that don't occur during painting. For example, there may be temporary buffers or a large amount of stack data that is needed during reflow which could reuse the memory allocated for the doublebuffer. In order to make the doublebuffer memory accessible we need to create the offscreen using the NS_CREATEDRAWINGSURFACE_FOR_PIXEL_ACCESS flag. We need to investigate what the overhead is of using this flag. On WIN32 this flag causes a DIB to be created. Will the overhead of creating and rendering to a DIB make reusing the doublebuffer memory infeasible? What happens if the video card has large amounts of memory? Will the offscreen be created using the video card's memory instead?.
interesting. This is something I always thought nsIMemory would provide somehow. It's sharing an arena of memory, and the consumers should be obvlivious to it. The tuning, checks, and reaction code necessary for this kind of sharing might hide problems in our use cases though, so maybe abstracting it too far would be a bad thing. Maybe the quick attempt is an existing arena impl that just gets passed around to everyone that want's to take a hit.
Summary: Investigate reusing the offscreen buffer used for doublebuffering → Investigate reusing the offscreen buffer used for doublebuffering
This won't work on X. The X server owns the memory (which you can't access directly).
It appears that the DDB's on WIN32 ARE allocated using video memory so there isn't any way to reuse the memory used for doublebuffering. As a test I placed calls to the WIN32:GlobalMemoryStatus before and after allocating the offscreen used for doublebuffering. If the offscreen is created as a DDB the difference between dwAvailVirtual before and after the call is 0 bytes. If the offscreen is created as a DIB the difference between dwAvailVirtual is equal to the size of the offscreen + approx 1K. So creating a DIB would be bad idea, since it will increase our memory consumption dramatically when the video card has sufficient memory to hold the offscreen DDB.
Marking fixed, since the investigation has been completed.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
Component: Layout: View Rendering → Layout: Web Painting
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.