The initial port of Android's extensions to the current libjpeg-turbo codebase is complete.
With Chao Yang's help we've validated using both the Linaro Android LEB panda as well as CyanogenMod 7 on the Nook. (I'd validate on my Nexus One too but I'm short of microSD cards)
It runs, image encode and decode tests pass and use of the library by android components such as the browser and skia appears to be fine with no issues. The past bugs seen with the 1.1.1 based proof of concept are gone.
The code can currently be found in git at:
http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.gi...
from the 1.2-beta-linaro-andoid branch.
Be sure to read the ANDROID.txt file for build instructions. This branch is SPECIFICALLY for android. It's not a wise idea (yet) to take these contents and use for a traditional linux system (tho I have also tested on linux with the extensions compiled in, I have not yet tested with all the extensions turned off to make sure a pre android build and a post android build without android support on are equal)
As soon as sourceforge sends me an email so I can confirm my account there, I'll get a patch posted to the libjpeg-turbo patch tracker for review. I anticipate there will be a comment or two and some slight rework here and there but generally speaking the code should be in good shape.
I have not yet started to do performance comparisons between the old jpeg and libjpeg-turbo on android. That needs to be done.
Further neon hardware support is assumed, likely there will be a patch to enable / disable optimization that counts on neon.
Also from the android extensions, support for ash and one optimization for armv6 was not included. Both however are reasonable optimizations and I can see including them at a future date.
I would include a pointer to the original android jpeg source but android.git.kernel.org is still down.
On Fri, Sep 02, 2011 at 10:34:47AM -0500, Tom Gall wrote:
The initial port of Android's extensions to the current libjpeg-turbo codebase is complete.
Tom, you've done a spectacular job carrying the -turbo work into the developer platform and now Android. I'm thrilled to see this come to fruition now, and the CyanogenMod test is a great bonus -- seeing this used on a real form-factor device means I can actually believe in it.
The code can currently be found in git at:
http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.gi...
from the 1.2-beta-linaro-andoid branch.
Be sure to read the ANDROID.txt file for build instructions. This branch is SPECIFICALLY for android.
Can you give a summary of what's being added here? i.e. what happened to Android when using libjpeg-turbo without these added patches?
I see some pretty major changes in:
http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.gi...
It looks to me like the main changes are protected by the following defines, which probably answers part of my question above:
ENABLE_ANDROID_NULL_CONVERT ANDROID_TILE_BASED_DECODE ANDROID_RGB
(Ald yes, I have read ANDROID.txt which confirms the above but doesn't tell me much else ;-)
Also, I see you adding config.h and jconfig.h files which I don't think you want to have committed, right?
Do you really want an android/ config subdirectory?
I have not yet started to do performance comparisons between the old jpeg and libjpeg-turbo on android. That needs to be done.
This might be Zach's next favorite demo!
You might want to try out the toolchain guys' latest -03 and assorted optimization madness to see if they make a difference when you do that.
Also from the android extensions, support for ash and one optimization for armv6 was not included. Both however are reasonable optimizations and I can see including them at a future date.
What is the "support for ash" piece?
Good job!
On Fri, Sep 2, 2011 at 10:51 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Fri, Sep 02, 2011 at 10:34:47AM -0500, Tom Gall wrote:
The initial port of Android's extensions to the current libjpeg-turbo codebase is complete.
Tom, you've done a spectacular job carrying the -turbo work into the developer platform and now Android. I'm thrilled to see this come to fruition now, and the CyanogenMod test is a great bonus -- seeing this used on a real form-factor device means I can actually believe in it.
Thanks!
It's been fun and the fun shall continue!
The code can currently be found in git at:
http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.gi...
from the 1.2-beta-linaro-andoid branch.
Be sure to read the ANDROID.txt file for build instructions. This branch is SPECIFICALLY for android.
Can you give a summary of what's being added here? i.e. what happened to Android when using libjpeg-turbo without these added patches?
For a more technical summary, the write up with the initial draft submitted patch is probably more interesting. It's perhaps a little too high level yet but for a patch of this size it's hard not to write a book. But in the interest of release early, release often, there it is.
https://sourceforge.net/tracker/?func=detail&aid=3403461&group_id=30...
I see some pretty major changes in:
http://git.linaro.org/gitweb?p=people/tomgall/libjpeg-turbo/libjpeg-turbo.gi...
It looks to me like the main changes are protected by the following defines, which probably answers part of my question above:
ENABLE_ANDROID_NULL_CONVERT ANDROID_TILE_BASED_DECODE ANDROID_RGB
Yes, everything is bounded by #ifdef ANDROID or akin. I'm kept to the mostly kept to the Android define philosophy for now but I think it reasonable to evolve the patch a bit and just go all ANDROID with the exception of testing for say android neon or support for ash.
(Ald yes, I have read ANDROID.txt which confirms the above but doesn't tell me much else ;-)
:-) Well it does say how to build it.
Also, I see you adding config.h and jconfig.h files which I don't think you want to have committed, right?
I do. Those are both generated by the autotools. Android does not use the autotools at all but these files must exist. Given there is no ./configure step in Android's build the next best thing is putting copies into the android directory and expect builders to copy/move them to the right place at build time. In my git tree however this step is not necessary, however that branch is the git tree is only for android.
Do you really want an android/ config subdirectory?
Unfortunately. There might be a better way around this, I don't know my Android build foo enough yet to see another method but perhaps some android types might comment.
I have not yet started to do performance comparisons between the old jpeg and libjpeg-turbo on android. That needs to be done.
This might be Zach's next favorite demo!
I have two Nexus Ones that I am going to install side by side. I think it might have some youtube potential :-)
You might want to try out the toolchain guys' latest -03 and assorted optimization madness to see if they make a difference when you do that.
Indeed. There's more to do.
Also from the android extensions, support for ash and one optimization for armv6 was not included. Both however are reasonable optimizations and I can see including them at a future date.
What is the "support for ash" piece?
Ash is Android Shared memory. http://elinux.org/Android_Kernel_Features#ashmem
Good job!
Thanks.
-- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs
-
Christian Robottom Reis -
Tom Gall