Replacing our JPEG library with a faster alternative?

[Hironori Bono (坊野 博典)]

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

[Mattias Nissler]

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]

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]

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]

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]

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]

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]

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]

> 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]

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]

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]

Wow, that date on that is today... how topical :)

Cheers

Chris

 

David

[Hironori Bono (坊野 博典)]

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

[Andrew Scherkus]

I was just thinking about using libjpeg-turbo today... in any case here's a bug we can use for continued discussion:

http://code.google.com/p/chromium/issues/detail?id=48789

Andrew