April 16, 2012

www-client/chromium and libjpeg-turbo

Recently Gentoo bug #412031 (">=www-client/chromium-18.0 should not force the media-libs/libjpeg-turbo dependency") has been filed. Samuli did the right thing and closed it, but I'd like to use this as an opportunity to explain the issue in more detail.

The original bug is #393471, filed by Gentoo Chromium team member Mike Gilbert four months ago and fixed in February. An optimization done in WebKit JPEG decoding code (which speeds up JPEG decoding by up to 2x) assumed that the code will run against the same version of JPEG library it has been compiled with. In general such assumptions do not hold (with the note of SONAMEs, i.e. same library SONAME should mean it's binary-compatible; more on that later), but Google Chrome bundles all of those third-party libraries anyway, so for Google it's true.

I started a discussion on chromium-dev mailing list, and also had direct e-mail exchange with developers doing the WebKit and libjpeg-turbo changes. The end result is we'd either have to keep a local patch in Gentoo to revert the optimization, or just always depend on libjpeg-turbo.

Of course the most cool would be to do the optimization The Right Way, by doing runtime detection of JPEG extensions, as made possible by DRC, libjpeg-turbo developer and explained in bug #393471 comment 23. jcstest.c in libjpeg-turbo source tree indeed shows how to do that. The only reason I haven't done that yet in WebKit is lack of time (it's not just producing the patch; compiling WebKit and running its layout tests takes a lot of it; and then dealing with any possible breakages), but I plan to do that in the future (help is welcome).

Speaking about The Right Way, another broken thing is that libraries that have the same SONAME (in this case libjpeg and libjpeg-turbo) behave differently when using JPEG extensions. You may recognize the libpng "breakages", but it seems to me libpng upstream actively cleans up the interface of the library, and it obviously updates SONAME accordingly. That's a good thing.

Hopefully it's now more clear why the Gentoo package www-client/chromium depends on libjpeg-turbo and not virtual/jpeg.