Bug 105405 – [EFL] Use libjpeg-turbo instead of libjpeg

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit EFL

[Thiago Marcos P. Santos]

Evaluate and if it the performance gain is considerable like the claims, start using it on the EFL port.

Ports like Chromium (bug 50054) and BB (bug 104152) have already made the switch.

[Thiago Marcos P. Santos]

Both libraries are binary compatible, so it would be probably a matter of installing libjpeg-turbo8-dev on your system instead of libjpeg8-dev. This bug will be probably more about enforcing or maybe issuing a warning in buildtime when libjpeg-turbo is not in use.

[Kenneth Rohde Christiansen]

From the Mer guys I heard that the performance gains are real and it is used in Mer and apparently also in Harmattan. It is also used by BlackBerry 10 and Chrome

[Jussi Kukkonen (jku)]

(In reply to comment #1)
> Both libraries are binary compatible, so it would be probably a matter of installing libjpeg-turbo8-dev on your system instead of libjpeg8-dev.

Note that AFAIK libjpeg-turbo is not 100% compatible with libjpeg 7 or 8, but only libjpeg 6b. This is probably not a problem but should be kept in mind.

License wise we should be good as it's nowadays under a BSD-style license completely.

Also, Mozilla uses libjpeg-turbo as well.

[Laszlo Gombos]

Do we have libjpeg-turbo8-dev on the relevant build bots ? I would think we should start there an make sure there are no regression.

I agree that we should support libjpeg-turbo8-dev - meaning that we should use libjpeg-turbo8 as our "golden/reference" environment that we test.

I think Slava has been using trunk with libjpeg-turbo for a while (CCd).

[Jussi Kukkonen (jku)]

(In reply to comment #4)
> I agree that we should support libjpeg-turbo8-dev - meaning that we should use libjpeg-turbo8 as our "golden/reference" environment that we test.

Oh wow, so there is a libjpeg-turbo that provides libjpeg.so.8.0.2 in Ubuntu nowadays... Reading the README the problems are still there -- not all of v8 features are supported -- but it looks like it's good enough for the big distros so I guess we should go with that.

I guess the least painful path is:
 1. perf testing to make sure there is an actual Win here
 2. Check for test regressions
 3. maybe also check the mozilla and chromium versions, they could 
    have patches we want
 4. add libjpeg-turbo to jhbuild and update wiki
 5. install packages on build bots

There's no need to modify source at all, is there (apart from jhbuild modules)?

[Jussi Kukkonen (jku)]

(In reply to comment #5)
>  1. perf testing to make sure there is an actual Win here

Using the patch in bug 103463, I informally tested the decoders using two different cat pictures (both baseline jpeg): I figured internet is mostly cat pictures so that should be very representative. 

libjpeg-turbo execution time was 70-75% _less_ than libjpeg in both cases. The variance of the results was fairly high, but even without statistical analysis I can promise that the results are significant: libjpeg-turbo is far faster.

I've not tried to test how much this might help on a image-heavy page, but it could be very noticeable: According to the decoder test, decoding 10 very large images can take (the order of) 1 second on my i5.

[Michael Catanzaro]

Closing this bug because the EFL port has been removed from trunk.

If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.