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