On Sat, Jan 28, 2012 at 1:33 PM, <jcupitt@xxxxxxxxx> wrote: > On 28 January 2012 06:10, Martin Nordholts <enselic@xxxxxxxxx> wrote: >> 2. Make GIMP clever. If GIMP encounters a tile with only values 0.0 >> and 1.0, the 32 bpc data can be transparently, i.e. without the user >> noticing, replaced with 1 bpc data. As soon as more bits of precision >> is required to avoid loss of data, GIMP can transparently convert the >> tile back to RGBA float. The same kind of optimization can be done for >> completely black, white and transparent tiles too. > > This sounds nice, though the problem with this approach is that you > need to scan each tile to work out what format it can be compressed > to. Instead of replacing tiles with 1bpc data, one can either compress the tile contents (trading of cpu use for io amount) or do a more generic de-duplication through hashing at runtime (based on an idle job combined with tracking revision numbers on tiles). Both are things that fit well in the GeglBuffer architecture, though the runtime dedup could have a rather large runtime cost. Such streaming compression of tile data as it is saved/loaded wouldn't be much slower than the current implementation. Though it likely be quite a bit slower than a mmap backed thing with a threaded tile writer.. (the hdd eating monster consumed a hdd with an almost working such implementation last year). /Øyvind K. «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ ; http://ffii.org/ _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gimp-developer-list
