summaryrefslogtreecommitdiff
path: root/third_party/libjpeg/fpdfapi_jdcoefct.c
diff options
context:
space:
mode:
authorbrucedawson <brucedawson@chromium.org>2016-06-27 06:58:37 -0700
committerCommit bot <commit-bot@chromium.org>2016-06-27 06:58:37 -0700
commit160bd0e26f5dfe5fa11322f61b3d156c2214cba8 (patch)
tree100685ec0eafbad5c7579eecde9ff1c2d2a96448 /third_party/libjpeg/fpdfapi_jdcoefct.c
parentafe3e4671b3f70e0459487aca89133a746c61797 (diff)
downloadpdfium-160bd0e26f5dfe5fa11322f61b3d156c2214cba8.tar.xz
Double AdobeCMYK_to_sRGB speed with faster rounding
FXSYS_round is painfully slow on Windows. It does range checking and then calls an extremely expensive function. It ends up consuming half the CPU time when decoding the images in PDFs such as this one: https://www.ets.org/Media/Tests/GRE/pdf/gre_research_validity_data.pdf SSE can be used to optimize this: __m128 cmyk = {c * 255, m * 255, y * 255, k * 255}; uint32_t output[4]; _mm_storeu_si128((__m128i*)output, _mm_cvtps_epi32(cmyk)); but is cryptic, only works for x86/x64, and gives basically identical performance to this solution - int(c * 255 + 0.5f); The rounding behavior is not identical but in practice this rarely matters, and in this specific case it does not matter because the edge cases that vary are not hit. The three divisions at the end were changed to multiplies because profiling showed they were a significant cost. This change reduces the image-decode stalls in the PDF listed above by about 40%, making for a noticeably better experience. Further optimizations are possible but would require significantly more time and testing. BUG=617365 Review-Url: https://codereview.chromium.org/2096723003
Diffstat (limited to 'third_party/libjpeg/fpdfapi_jdcoefct.c')
0 files changed, 0 insertions, 0 deletions