We're getting pretty far off topic here--even for this thread. J On Wed, Oct 27, 2010 at 2:22 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/27/10 7:12 AM, Keean Schupke wrote: > >> Actually the problem with this is the internal memory usage by the >> browser to have a single page with 5000 divs in a list, each of which >> has a layout with say 20 elements, so about 100,000 elements. The memory >> used by the browser for the DOM tree >> > > In 64-bit Gecko (the numbers are smaller in a 32-bit build) a <div> is 56 > bytes. So 100,000 of them (and using 20 elements for layout is a _lot_ of > elements, btw) is 5.6MB of RAM used. > > Your typical low-end device nowadays has 64MB of RAM, right? So if the > above is all you're looking at you're more or less ok. And again, if you're > using 20 elements for layout then you're probably doing it wrong. > > and rendering >> > > This is a much bigger problem, in my experience. Gecko implements some XUL > rendering classes that try to solve this problem by only creating rendering > objects for the things that are visible in the viewport, subject to various > limitations. We've been thinking about ways to try to generalize this to > web content... > > > is the problem, so I don't think (correct me if I am wrong) the >> Flyweight pattern can help. >> > > Browsers use exactly that pattern already to reduce the memory used by DOM > and rendering. And the things we've been thinking about mentioned above > also work similarly. > > > To get round this we only create enough divs to fill the screen, and >> cycle them round by catching onscroll events. This is just about fast >> enough - but was something I had to implement for our web developers as >> a library due to the complexity. >> > > Right; the idea would be to move this sort of thing into the browser core. > > -Boris >
Received on Wednesday, 27 October 2010 13:35:42 UTC