Hello On 18.09.09, you wrote:
> > The upshot of this is that memory requirements for bitmaps becomes > significantly smaller -- taking the screenshots directory (and > subdirectories) from the website source tree results in the compressed > format described above requiring, on average, 12.26% of the memory that you mean 12,6% of bitmap image ? But to be realistic you should count the whole memory some pages need and how many kb overall you can save with that feature and then calculate how many more pages you can show for example with a 64 megabyte system. and then see how many speedloss it do.also remember if a png tile is used as a background then if the tile is repeat, the code must either depack it once or repack it often. how is the Situation on slow risc OS Systems ? On amiga 68k system, the CPU speed is the weak point.the systems can enhance to 128 megabyte and that is much enough mem. if netsurf maybe use caches, then more memory is need, but i think today DSL is so fast, that on systems that have a slow CPU and so maybe also few mem, there is no cache need, because they render pages so slow, that the wait for data and DSL is maybe not so much as storing and searching data for cache. I use a emulate 68k system on windows that give round about 800 MHZ native 68k speed. I test netsurf with a cache proxy on windows side. with that speed i notice some speedup. but on the emulate 68k, i can switch off the JIT and then it run as fast as a 68k 30 MHZ CPU. Then there is no speedup see on pages. > > Some questions: > > 1) Is it worth pursuing this further? I think more priority should be, complete and bugfix the render engine > 2) What kind of API do people want? Right now, when wanting to redraw, > the client passes a row callback which is called for every scanline > in the specified clipping region. The bitmap data fed to the > callback is uncompressed 32bpp RGBA. The callback is responsible for > actually outputting the scanline (including any alpha blending, > colour-space conversion, and scaling). > > Given that changing the way in which bitmaps work impacts many bits of > the core and frontends, I'd not be intending to even start a transition > until we've sorted out content caching. > > > J. > Regards
