summaryrefslogtreecommitdiffstats
path: root/src/3rdparty/libjpeg/src/README.md
diff options
context:
space:
mode:
authorEirik Aavitsland <eirik.aavitsland@qt.io>2019-10-23 16:30:29 +0200
committerEirik Aavitsland <eirik.aavitsland@qt.io>2019-10-25 14:33:11 +0200
commitf3dbe98dca58731ff98dff3cc9111a8252f8e1e6 (patch)
treedb3f7655ac00bce2766ea7d6c2b0ebf23b1c3dc4 /src/3rdparty/libjpeg/src/README.md
parent2fac76e719fcc3889441af08e71c2decb106676a (diff)
Update bundled libjpeg-turbo to version 2.0.3
[ChangeLog][Third-Party Code] libjpeg-turbo was updated to version 2.0.3 Task-number: QTBUG-79420 Change-Id: I9f9b8b3a913fd5843759c0610f43b22c5bee67dc Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Diffstat (limited to 'src/3rdparty/libjpeg/src/README.md')
-rw-r--r--src/3rdparty/libjpeg/src/README.md28
1 files changed, 19 insertions, 9 deletions
diff --git a/src/3rdparty/libjpeg/src/README.md b/src/3rdparty/libjpeg/src/README.md
index a769259891..c61b855644 100644
--- a/src/3rdparty/libjpeg/src/README.md
+++ b/src/3rdparty/libjpeg/src/README.md
@@ -135,12 +135,11 @@ without recompiling. libjpeg-turbo does not claim to support all of the
libjpeg v7+ features, nor to produce identical output to libjpeg v7+ in all
cases (see below.)
-By passing an argument of `--with-jpeg7` or `--with-jpeg8` to `configure`, or
-an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you can build a
-version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so that
-programs that are built against libjpeg v7 or v8 can be run with libjpeg-turbo.
-The following section describes which libjpeg v7+ features are supported and
-which aren't.
+By passing an argument of `-DWITH_JPEG7=1` or `-DWITH_JPEG8=1` to `cmake`, you
+can build a version of libjpeg-turbo that emulates the libjpeg v7 or v8 ABI, so
+that programs that are built against libjpeg v7 or v8 can be run with
+libjpeg-turbo. The following section describes which libjpeg v7+ features are
+supported and which aren't.
### Support for libjpeg v7 and v8 Features
@@ -247,9 +246,8 @@ don't, and it allows those functions to be provided in the "official"
libjpeg-turbo binaries.
Those who are concerned about maintaining strict conformance with the libjpeg
-v6b or v7 API can pass an argument of `--without-mem-srcdst` to `configure` or
-an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to building
-libjpeg-turbo. This will restore the pre-1.3 behavior, in which
+v6b or v7 API can pass an argument of `-DWITH_MEM_SRCDST=0` to `cmake` prior to
+building libjpeg-turbo. This will restore the pre-1.3 behavior, in which
`jpeg_mem_src()` and `jpeg_mem_dest()` are only included when emulating the
libjpeg v8 API/ABI.
@@ -344,3 +342,15 @@ quality of 98-100. Thus, libjpeg-turbo must use the non-SIMD quantization
function in those cases. This causes performance to drop by as much as 40%.
It is therefore strongly advised that you use the slow integer forward DCT
whenever encoding images with a JPEG quality of 98 or higher.
+
+
+Memory Debugger Pitfalls
+========================
+
+Valgrind and Memory Sanitizer (MSan) can generate false positives
+(specifically, incorrect reports of uninitialized memory accesses) when used
+with libjpeg-turbo's SIMD extensions. It is generally recommended that the
+SIMD extensions be disabled, either by passing an argument of `-DWITH_SIMD=0`
+to `cmake` when configuring the build or by setting the environment variable
+`JSIMD_FORCENONE` to `1` at run time, when testing libjpeg-turbo with Valgrind,
+MSan, or other memory debuggers.