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
Mandeep Kumar writes:
>> Vladimir Pantelic writes:
>>
>> > Mandeep Kumar wrote:
>> >> Hi All,
>> >>
>> >> I have done some benchmarking on OMAP4 running Ubuntu for various
>> >> versions of libjpegs. Benchmarks were collected with
>> >> modified version of djpeg that prints out ms time taken fo
Vladimir Pantelic writes:
> Mandeep Kumar wrote:
>> Hi All,
>>
>> I have done some benchmarking on OMAP4 running Ubuntu for various versions
>> of libjpegs. Benchmarks were collected with
>> modified version of djpeg that prints out ms time taken for decoding. Sample
>> used for benchmarking i
Måns Rullgård wrote:
> Mandeep Kumar writes:
>
>>> Vladimir Pantelic writes:
>>> > Either I am doing something wrong or this libjpeg-turbo is not so turbo.
>>>
>>> Libjpeg (turbo or regular) is full of inefficiencies. I guess they all
>>> add up.
>>>
>> My numbers should only be used for
My numbers should only be used for relative comparison purpose as djpeg
decoding time that I sent also include time to read input file from
filessystem. Actual decoding speed may be higher when special modification
are done in djpeg application to read input from memory.
Thanks & Regards,
Mandeep
Mandeep Kumar wrote:
Hi All,
I have done some benchmarking on OMAP4 running Ubuntu for various versions of
libjpegs. Benchmarks were collected with
modified version of djpeg that prints out ms time taken for decoding. Sample
used for benchmarking is a 12MP image
downloaded from a photography
Hi All,
I have done some benchmarking on OMAP4 running Ubuntu for various versions
of libjpegs. Benchmarks were collected with modified version of djpeg that
prints out ms time taken for decoding. Sample used for benchmarking is a
12MP image downloaded from a photography website. Here are the res
Vladimir Pantelic writes:
> On 06/24/2011 08:13 PM, Woodruff, Richard wrote:
>
>>> 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 th
We've got a BP for this:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-try-libjpeg-turbo
On 23 June 2011 03:30, Alexander Sack wrote:
> On Thu, Jun 23, 2011 at 3:30 AM, Christian Robottom Reis
> wrote:
>> Hi there,
>>
>> I took a look at the AOSP libjpeg code which is
On 06/24/2011 08:13 PM, Woodruff, Richard wrote:
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 probabl
> From: linaro-dev-boun...@lists.linaro.org [mailto:linaro-dev-
> boun...@lists.linaro.org] On Behalf Of Christian Robottom Reis
> Sent: Wednesday, June 22, 2011 8:30 PM
> This suggests to me that a simple drop-in of libjpeg-turbo might be
> actually easy to do, and that there is probably a signi
On 23/06/11 11:30, Alexander Sack wrote:
> sounds good. Seems like a great starter project for MM WG to get their
> hands dirty on android.
>
> They could have three builds:
>
> 1. plain LEB
> 2. LEB with mans optimized libjpeg
> 3. LEB with libjpeg-turbo
>
> Then benchmark all three and keep
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
On Thu, Jun 23, 2011 at 3:30 AM, 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
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:
15 matches
Mail list logo