Yes, I'd think we'd want to merge the v6 support into libjpeg-turbo and verify its correct operation before trying to replace the version of libjpeg in Android. Also, v6 would need to be selected using the same mechanisms (or similar) to the ones we currently use to select NEON.
I also wanted to let you guys know that I have set up a libjpeg-turbo-devel list (https://lists.sourceforge.net/lists/listinfo/libjpeg-turbo-devel) which can be used to submit patches to the project or talk about development topics specific to the libjpeg-turbo code. You can also use the Patch tracker on Sourceforge to submit patches and discuss them. On 6/22/11 8:30 PM, Christian Robottom Reis wrote: > Hi there, > > I took a look at the AOSP libjpeg code which is included in > > git://android.git.kernel.org/platform/external/jpeg > > during my flight back home (which incidentally had been diverted and > landed me in Rio de Janeiro; not sure if I celebrate or cry) and noted > the following things: > > - There is a v6 implementation of the fast IDCT algorithm which > lives in armv6_idct.S. > > - The commit which adds this implementation was added October 2010, > and there haven't been any changes since. > > - The code that selects the decoder IDCT implementation in > jddctmgr.c always uses that implementation if ANDROID_ARMV6_IDCT > is defined. > > - Google have an "ashmem" backing store implementation, and have > code to enable tile-based mode. It's a fairly non-intrusive change > to use ashmem since it just replaces jpeg_open_backing_store. > > - The code is pretty much standard libjpeg without any structural > changes to it. > > - There isn't any NEON code in this branch. > > - Mans has an optimized version here: > > http://git.mansr.com/?p=libjpeg;a=summary > > I don't know if he's submitted this to AOSP or not. > > This suggests to me that a simple drop-in of libjpeg-turbo might be > actually easy to do, and that there is probably a significant > performance benefit to be achieved. One thing to keep in mind is that > this code still supports armv6, so we'd probably want to preserve that. > > Thanks! _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
