On Mon, 23 Apr 2012 15:05:09 +0200 thomasg <tho...@gstaedtner.net> said:
> On Sun, Apr 22, 2012 at 05:58, Carsten Haitzler <ras...@rasterman.com> wrote: > > On Sat, 21 Apr 2012 12:08:18 +0200 Vincent Torri <vincent.to...@gmail.com> > > said: > > > > actually forget lz4hc... lgpl3. > > > >> hey > >> > >> just found that while reading the gnutls ML : > >> > >> http://code.google.com/p/lz4/ > >> > >> it seems that it allows the same ratio for compression than zlib but > >> seems to be by far faster than zlib > >> > >> the memory consumption should be tested too. > >> > >> What do you think ? > >> > >> Vincent > >> > >> ------------------------------------------------------------------------------ > >> For Developers, A Lot Can Happen In A Second. > >> Boundary is the first to Know...and Tell You. > >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > >> http://p.sf.net/sfu/Boundary-d2dvs2 > >> _______________________________________________ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) ras...@rasterman.com > > > > > > ------------------------------------------------------------------------------ > > For Developers, A Lot Can Happen In A Second. > > Boundary is the first to Know...and Tell You. > > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > > http://p.sf.net/sfu/Boundary-d2dvs2 > > _______________________________________________ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > I don't see any problem using an LGPLv3 library. Are there really any > changes necessary to make use of it in eet? Also, would it have to be > distributed in a way where LGPL parts would actually be packed into an > Eet binary or Eet source code? there i a problem because we'd have to compile it into eet - which would make eet lgpl3. gpl and lgpl3 are also highly propblematice in terms of acceptance. they are controversial at best. > Although I of course can understand that it would not be possible to > use Eet in an environment where no LGPL library could be accepted, > wherever or whyever that would be. no, it's the gpl/lgpl3 (as opposed to 2). > Other than that, would it really be worth it? Even if in the best case > the compression is only a little worse than zlib and compression time > would be a lot faster - would it really be worth it? compression time for just a little worse than zlib is the same as zlib. for 30% less compression compression is 7x faster and decompression 6x faster. forget the hc lgpl3 variant. we just gain on decompress speed here. its the normal one with the size loss that smells interesting. > Eet usually is used WORM-style (Write Once / Read Many), so > compression time is hardly an issue - but if decompression is indeed this is minimally interesting, well until we are generating edj files on the fly as you type in an edje editor thing that lets u edit and see previews on the fly... :) > not significantly faster (or even slower?), and file size is larger (thus decompression 6x faster - see my other mail. that means load times for config data and edj files could be improved by this. > I/O, which more often than not is a bottle-neck nowadays, being lower) > you'd actually not gain anything but lose run-time performance > instead. for uncached (first run) yes - for repeated re-load on cached data... it will help. :) > On the lz4hc page I only spotted compression benchmarks, nothing about > decompression - if basic information is missing, there usually is a > reason. > > If anything, what would make sense for Eet would be the XZ format, using LZMA. > Compared to zlib, compression is a lot slower, but decompression is > not much slower - and compression ratio and through that I/O > throughput a lot higher. > XZs liblzma is LGPLv2.1 though. maybe - as above. depends on if its cached or uncached. :) > Lastly: why would it be trouble supporting additional compression > methods? Eet uses file format versions in the binary, right? Why not > have features supported starting from a certain format version? Sure, > that would make old files incompatible but would this really be an no - the other way. newer files (edj files/themes) dont work with older eet/edje's etc. > API-break? As I see it it would just mean newer files, or programs > using newer files, would have to depend on a newer minor release of > Eet without any actual API changes (in any case though it is an ABI > change for the Eet files I guess). > A way to do such a change might be having a new major release for it > and default to the old zlib compression, so users who require for > example XZ support can depend on it properly and not risk producing > files nobody can use, for no reason. we have it already. this is a pretty big change though. a while new compression scheme that cannot be read by older installs. we can of course just say "new edj files cant load on older edje libs". sooner or later this will become the case anyway, but this is a big big big change. > ~thomasg > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
