On 10/27/11 2:30 PM, Siarhei Siamashka wrote:
> Also huffman decoder optimizations (which are C code, not SIMD) in
> libjpeg-turbo seem to be providing only some barely measurable
> improvement on ARM, while huffman speedup is clearly more impressive
> on x86. This gives libjpeg-turbo more points o
Hi. If you are attempting to cross-post to both linaro-dev and
libjpeg-turbo-devel, please subscribe to libjpeg-turbo-devel.
Otherwise, every time you CC libjpeg-turbo-devel, the message will
automatically be moderated, and I have to manually log in and approve
each one.
DRC
Sounds good. Siarhei has just submitted a new patch for implementing
accelerated ISLOW decoding, and he plans to tweak that over the coming
days. Unless anyone sees a reason not to, I would like to release the
official libjpeg-turbo 1.2 beta in September or early October.
On 7/22/64 1:59 PM, To
I still posit that it's possible to avoid many of those inefficiencies by using
a sufficiently large buffer in libjpeg-turbo and using an in-memory
source/destination manager. Much of the inefficiency in the code relates to the
buffering that it does to avoid reading the entire image into memory
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
Just FYI-- for those interested in the ARM porting effort in
libjpeg-turbo, the iOS and Android camps reached a resolution, and the
patches they agreed upon have been committed to trunk. Independent
evaluation by any of you who have an interest in this would be very much
appreciated.
On 6/14/11
