Hi Cedric, Just to let you know I'm trying to review whenever I have some time. Since we will meet next week, we can discuss it IRL. So far I don't have anything to comment specifically though.
Apparently no one else can be bothered to go through your massive change all at once. That's the drawback of branches I guess :) Best regards, On Sun, Mar 1, 2015 at 11:17 PM, Cedric BAIL <[email protected]> wrote: > Hello, > > I have been working for a long time on refactoring our compression and > ciphering code into a library that I named emile. It is available for > review in my branch devs/cedric/emile. Please give it a look, it is > nearing readiness for inclusion. Maybe for later this week if nothing > big come from the review. > > The library provide so far JPEG and ETC based codec for lossy format. > It provide an easy to use Eina_Binbuf for Zlib and LZ4 lossless > decompression. There is also currently 2 crypto backend, one with > gnutls and another one with openssl. > > What is done : > - One colorspace definition to unite them all (Eet and Evas for now). > - Full refactoring using provided Emile functions of Eet and Evas. > - Improved logic to open JPEG in ARGB8888, GRY8 and AGRY88. > - Optimistic initialization of GNUTLS/OpenSSL (This solve the issue of > using GNUTLS backend with root binary and improve the startup time of > efl). > > What is not done : > - Migrating Ecore_Con_SSL to use Emile. That's why the relevant Emile > API is marked as beta and is not documented. > - There is no Emile code for saving image yet, only loader. Reason is > that the loader API is pretty similar in Eet and Evas. It has been > used with little change over a long period of time and is quite > straight forward to abstract in a common piece of code. This is not > the same for saver, so that's on the side for now. > - There is yet no serializer in Emile. > > This code already has some benefit to be included and the todo is > going to expand over time as we identify more common pattern among our > library, so waiting for it to be done doesn't make sense. This library > doesn't introduce new dependencies (as it is only a refactoring) and > actually reduce the overall code we have. > > This is also a low level library that could be used by anything above > Eina. That's why it doesn't use Eo or any of the above stack and it is > not planned to change as I want to be able to use some of this code in > Eo at some point. > > Have fun, > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Jean-Philippe André ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
