Replacing our JPEG library with a faster alternative?

1124 views
Skip to first unread message

Hironori Bono (坊野 博典)

unread,
Jul 23, 2010, 7:07:29 AM7/23/10
to Chromium-dev
Greetings chromium developers,

As you know, Chromium uses IJG libjpeg as its JPEG library at least on
Windows. Today, I added a PageCyclerTest.JpegTestFile (*1)(*2),
replaced this libjpeg with libjpeg-turbo (*3)(*4), and compared their
results on my Windows PC just for my personal interest. To summarize
the results, Chromium (+ libjpeg-turbo) can decode JPEG files almost
twice as fast as the original one as listed below. (Please see the
attached files for their full results.) Even though the real web pages
does not include so many huge JPEG files used in this test and
libjpeg-turbo does not improve the performance of Chromium as much as
this test, it might be a good idea to consider replacing our JPEG
library to a faster alternative?

* Chromium r53428
- PageCyclerTest.JpegTestFile: 63565 ms
* Chromium r53428 + libjpeg-turbo
- PageCyclerTest.JpegTestFile: 33283 ms

(*1) <http://codereview.chromium.org/2819064>
(*2) <http://codereview.chromium.org/2861076>
(*3) <http://sourceforge.net/projects/libjpeg-turbo/>
(*4) I manually built its static library and replaced it with our
libjpeg since this is just an initial test.

Regards,

Hironori Bono
E-mail: hb...@chromium.org

jpegtest-libjpeg.txt
jpegtest-libjpeg-turbo.txt

Mattias Nissler

unread,
Jul 23, 2010, 7:16:40 AM7/23/10
to Chromium-dev
And now from the correct address, sorry.

On Fri, Jul 23, 2010 at 1:14 PM, Mattias Nissler <mnis...@google.com> wrote:
Impressive! How seriously do they take cross-platform compatibility and response times to security issues? I understand it's a drop-in replacement for libjpeg, so you might want to make an experiment and rerun your tests on different platforms?


--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev


Mike Belshe

unread,
Jul 23, 2010, 2:01:30 PM7/23/10
to mnis...@chromium.org, Chromium-dev
Hironori - 

Looks very promising!

BTW - I've always thought that image decoding was a task ripe for worker threads; we should be able to decodes in parallel.

Mike

Ian Fette

unread,
Jul 23, 2010, 2:11:25 PM7/23/10
to mbelshe...@google.com, mnis...@chromium.org, Chromium-dev
Is there any significant difference in binary size when you compile with the new library? (I expect not, but just double checking)

-ian

Peter Kasting

unread,
Jul 23, 2010, 3:08:31 PM7/23/10
to hb...@chromium.org, Chromium-dev
On Fri, Jul 23, 2010 at 4:07 AM, Hironori Bono (坊野 博典) <hb...@chromium.org> wrote:
Even though the real web pages
does not include so many huge JPEG files used in this test and
libjpeg-turbo does not improve the performance of Chromium as much as
this test, it might be a good idea to consider replacing our JPEG
library to a faster alternative?

Seems worth doing to me as long as it tracks libjpeg closely (for security reasons), continues to be maintained, doesn't have its own new bugs, etc.

PK

stoyan

unread,
Jul 23, 2010, 3:49:49 PM7/23/10
to pkas...@google.com, hb...@chromium.org, Chromium-dev
Anyone considered using GPU for JPEG decompression? At least DCT part
of JPEG decompression could be offloaded to the GPU. There is a
sample on the NVIDIA site
http://developer.download.nvidia.com/SDK/9.5/Samples/gpgpu_samples.html#gpgpu_dct
- Discrete Cosine Transform.
Might be worth investigating.

Stoyan

Antoine Labour

unread,
Jul 23, 2010, 3:58:26 PM7/23/10
to sto...@chromium.org, pkas...@google.com, hb...@chromium.org, Chromium-dev
On Fri, Jul 23, 2010 at 12:49 PM, stoyan <sto...@chromium.org> wrote:
Anyone considered using GPU for JPEG decompression? At least DCT part
of JPEG decompression could be offloaded to the GPU. There is a
sample on the NVIDIA site
http://developer.download.nvidia.com/SDK/9.5/Samples/gpgpu_samples.html#gpgpu_dct
- Discrete Cosine Transform.
Might be worth investigating.

Stoyan

It's only useful if the image is only used on the GPU (i.e. accelerated compositing all the way). The transfer costs (especially reading back), and the extra significant latency would far outweigh the computational perf benefits if any.

Antoine

Peter Kasting

unread,
Jul 23, 2010, 4:14:20 PM7/23/10
to Antoine Labour, sto...@chromium.org, hb...@chromium.org, Chromium-dev
On Fri, Jul 23, 2010 at 12:58 PM, Antoine Labour <pi...@chromium.org> wrote:
On Fri, Jul 23, 2010 at 12:49 PM, stoyan <sto...@chromium.org> wrote:
Anyone considered using GPU for JPEG decompression? At least DCT part
of JPEG decompression could be offloaded to the GPU. There is a
sample on the NVIDIA site
http://developer.download.nvidia.com/SDK/9.5/Samples/gpgpu_samples.html#gpgpu_dct
- Discrete Cosine Transform.
Might be worth investigating.

Stoyan

It's only useful if the image is only used on the GPU (i.e. accelerated compositing all the way). The transfer costs (especially reading back), and the extra significant latency would far outweigh the computational perf benefits if any.

FWIW, we pay a large penalty for images today, and I was just chatting with jamesr about this yesterday.

Decoded images sit around in 32bpp uncompressed ARGB format.  (Animated GIFs are even worse because you have one of these for every frame.)  This quickly blows out the memory cache, which is especially limited on Chrome since we try to split our memory cache across multiple processes.  As a consequence, going to Google Maps with a reasonably large window will cause the map tiles to basically evict everything else.

It would be much better if we could decode directly to a texture on the video card, and let the card handle keeping the texture around.  As noted above, this would imply a significantly different painting architecture, one which avoids Skia and does everything directly on the GPU.  But if we had such a thing, not only would compositing be faster and decoding GPU-acceleratable, we could avoid wasting memory cache on decoded images, allowing much more aggressive caching of more other resources, which are generally small compared to a single large decoded image.

So please feel free to consider such major changes :)

PK

Evan Stade

unread,
Jul 23, 2010, 5:29:35 PM7/23/10
to pkas...@google.com, Antoine Labour, sto...@chromium.org, hb...@chromium.org, Chromium-dev
> we could avoid wasting memory cache on decoded images,
> allowing much more aggressive caching of more other resources, which are
> generally small compared to a single large decoded image.
> So please feel free to consider such major changes :)
> PK

can/do we reserve part of the memory cache for not-images

Chris Evans

unread,
Jul 23, 2010, 6:52:17 PM7/23/10
to pkas...@google.com, hb...@chromium.org, Chromium-dev
On Fri, Jul 23, 2010 at 12:08 PM, Peter Kasting <pkas...@google.com> wrote:
Interestingly, libjpeg hasn't really had a security bug for over a decade (look when jpeg-6b was released!)
We'd need to security review this "turbo" version though in case it introduced any security errors.

Cheers
Chris


PK

David Benjamin

unread,
Jul 23, 2010, 7:15:57 PM7/23/10
to cev...@chromium.org, pkas...@google.com, hb...@chromium.org, Chromium-dev
On Fri, Jul 23, 2010 at 3:52 PM, Chris Evans <cev...@chromium.org> wrote:
> Interestingly, libjpeg hasn't really had a security bug for over a decade
> (look when jpeg-6b was released!)
> We'd need to security review this "turbo" version though in case it
> introduced any security errors.

I did a quick search and came across this:
https://bugzilla.redhat.com/show_bug.cgi?id=617469

David

Chris Evans

unread,
Jul 23, 2010, 7:24:38 PM7/23/10
to David Benjamin, pkas...@google.com, hb...@chromium.org, Chromium-dev
Wow, that date on that is today... how topical :)

Cheers
Chris
 


David

Hironori Bono (坊野 博典)

unread,
Jul 26, 2010, 8:41:31 AM7/26/10
to Chromium-dev
Greetings,

Thank you so much for your comments. (I have never imagined I could
receive so many comments.)
Firstly, I realize many people are afraid of replacing our JPEG
library and I don't have any intention of rushing into it. (I just
would like to start a discussion about it since I thought it was worth
for it.) So, I would apologize for those who had negative impressions
about my sudden e-mail.

By the way, I would like to add some more data to answer questions.

1. Platforms
To see the package files
<https://sourceforge.net/projects/libjpeg-turbo/files/>, libjpeg-turbo
seems to work on many Intel platforms (including Windows, Mac, and
Linux). I compile libjpeg-turbo on my Linux PCs (x86 and x64). I'm
going to try compiling it on my macbook tomorrow.

2. File size
To compare the sizes of the original chrome.dll and the patched one,
the patched one is a little bigger (0.47%).
* chrome.dll
- r53609: 26,148,864 bytes
- r53609 + libjpeg-turbo: 26,274,304 bytes (comp. 100.47%)

3. PageCyclerTest
I have run PageCycler*Test.MozFile on my Win PC today to compare their
results. To summarize their results, the patched one runs a little
faster (by 4.25%) even though the PageCyclerTest.MozFile does not
include so many JPEG files. (See "mozfile.txt" and
"mozfile-libjpeg-turbo.txt" for their full results.)

* PageCyclerTest.MozFile
- r53609: (23592 + 22706 + 22599) / 3 = 22965.6
- r53609 + libjpeg-turbo: (21810 + 22115 + 22045) / 3 = 21990.0 (comp. 95.75%)
* PageCyclerReferenceTest.MozFile
- r53609: (22539 + 22080 + 22463) / 3 = 22360.6
- r53609 + libjpeg-turbo: (22244 + 22157 + 22233) / 3 = 22211.3 (comp. 99.33%)
* PageCyclerExtensionTest.MozFile
- r53609: (22505 + 22986 + 22736) / 3 = 22742.3
- r53609 + libjpeg-turbo: (22565 + 22185 + 22510) / 3 = 22420.0 (comp. 98.58%)

4. Compatibility/Security Issues.
I totally agree that we should not change our JPEG library until we
can verify it is safe and it does not have any compatibility issues
with the original one.
As for Fedora Bug 617469
<https://bugzilla.redhat.com/show_bug.cgi?id=617469>, I wrote a quick
fix for this bug ("jdhuff.diff", which just copied the boundary check
in the original JPEG library) and compared the performance of my
patched libjpeg-turbo with the original one ("jpgtest-results.txt").
To summarize the results, I cannot see remarkable differences between
them on my Win PC. (Maybe I should send my patch and the test results
to the author of libjpeg-turbo so Fedora people become happy?)

Finally, I would appreciate all those who gave me your comments once
again. They are definitely helpful for me to clarify what we need to
move forward.

Regards,

Hironori Bono
E-mail: hb...@chromium.org

mozfile.txt
mozfile-libjpeg-turbo.txt
jdhuff.diff
jpgtest-results.txt

Andrew Scherkus

unread,
Sep 8, 2010, 3:31:32 PM9/8/10
to hb...@chromium.org, Chromium-dev
I was just thinking about using libjpeg-turbo today... in any case here's a bug we can use for continued discussion:


Andrew

Reply all
Reply to author
Forward
0 new messages