Use libjpeg-turbo in place of libjpeg
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the libjpeg package to meta-oe for applications which may depend on API version 9.
[YOCTO #8628]
Maxin B. John (2):
libjpeg: Replace libjpeg with libjpeg-turbo
libjpeg-turbo: import the recipe from meta-oe
meta/recipes-core/jpeg/jpeg_9a.bb | 29 ----------------- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 2 files changed, 40 insertions(+), 29 deletions(-) delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
Signature · 1 line
2.4.0
PATCH 1/2 libjpeg: Replace libjpeg with libjpeg-turbo
Removing libjpeg from oe-core to replace it with libjpeg-turbo.
--- meta/recipes-core/jpeg/jpeg_9a.bb | 29 ----------------------------- 1 file changed, 29 deletions(-) delete mode 100644 meta/recipes-core/jpeg/jpeg_9a.bb
meta/recipes-core/jpeg/jpeg_9a.bb deleted +0 -29
@@ -1,29 +0,0 @@ -SUMMARY = "libjpeg is a library for handling the JPEG (JFIF) image format" -DESCRIPTION = "libjpeg contains a library for handling the JPEG (JFIF) image format, as well as related programs for accessing the libjpeg functions." -HOMEPAGE = "http://www.ijg.org/" - -LICENSE ="BSD-3-Clause" -LIC_FILES_CHKSUM = "file://README;md5=ea93a8a2fed10106b63bc21679edacb9" - -SECTION = "libs" - -SRC_URI = "http://www.ijg.org/files/jpegsrc.v${PV}.tar.gz \ - " - -SRC_URI[md5sum] = "3353992aecaee1805ef4109aadd433e7" -SRC_URI[sha256sum] = "3a753ea48d917945dd54a2d97de388aa06ca2eb1066cbfdc6652036349fe05a7" - -inherit autotools - -PACKAGES =+ "jpeg-tools " -DESCRIPTION_jpeg-tools = "The jpeg-tools package includes the client programs for access libjpeg functionality. These tools allow for the compression, decompression, transformation and display of JPEG files." -FILES_jpeg-tools = "${bindir}/*" - -BBCLASSEXTEND = "native" - -pkg_postinst_${PN}_linuxstdbase () { - if [ ! -e $D${libdir}/libjpeg.so.62 ]; then - JPEG=`find $D${libdir} -type f -name libjpeg.so.\*.\*.\*` - ln -sf `basename $JPEG` $D${libdir}/libjpeg.so.62 - fi -}
Signature · 1 line
2.4.0
PATCH 2/2 libjpeg-turbo: import the recipe from meta-oe
In reply to Maxin B. Johnlibjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.
[YOCTO #8628]
--- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +40 -0
@@ -0,0 +1,40 @@ +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression" +HOMEPAGE = "http://libjpeg-turbo.org/" + +LICENSE = "BSD-3-Clause" +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \ + file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \ + file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \ +" + +DEPENDS = "nasm-native" + +BASEPV = "${@d.getVar('PV',True).split('+')[1]}" + +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz" +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2" +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" + +S = "${WORKDIR}/${BPN}-${BASEPV}" + +# Drop-in replacement for jpeg +PROVIDES = "jpeg" +RPROVIDES_${PN} += "jpeg" +RREPLACES_${PN} += "jpeg" +RCONFLICTS_${PN} += "jpeg" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--with-jpeg8 " + +PACKAGES =+ "jpeg-tools libturbojpeg" + +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality. These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library." +FILES_jpeg-tools = "${bindir}/*" + +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" +INSANE_SKIP_libturbojpeg = "dev-so" + +BBCLASSEXTEND = "native" + +LEAD_SONAME = "libjpeg.so.8"
Signature · 1 line
2.4.0
Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe
Quoted 2 lines · Maxin B. John
libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.
Is this imported as-is from meta-oe? If so then at least mention it in commit message and sent libjpeg-turbo removal for meta-oe.
Quoted 63 lines
[YOCTO #8628]
Signed-off-by Maxin B. John <[email protected]>--- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bbmeta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +40
-0@@ -0,0 +1,40 @@ +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression" +HOMEPAGE = "http://libjpeg-turbo.org/" + +LICENSE = "BSD-3-Clause" +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \ + file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \ + file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \ +" + +DEPENDS = "nasm-native" + +BASEPV = "${@d.getVar('PV',True).split('+')[1]}" + +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz" +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2" +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" + +S = "${WORKDIR}/${BPN}-${BASEPV}" + +# Drop-in replacement for jpeg +PROVIDES = "jpeg" +RPROVIDES_${PN} += "jpeg" +RREPLACES_${PN} += "jpeg" +RCONFLICTS_${PN} += "jpeg" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--with-jpeg8 " + +PACKAGES =+ "jpeg-tools libturbojpeg" + +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality. These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library." +FILES_jpeg-tools = "${bindir}/*" + +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" +INSANE_SKIP_libturbojpeg = "dev-so" + +BBCLASSEXTEND = "native" + +LEAD_SONAME = "libjpeg.so.8"Signature · 7 lines
2.4.0 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe
Hi Martin,
Quoted 7 lines · Martin Jansa
Quoted 2 lines · Maxin B. John
libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.
Is this imported as-is from meta-oe? If so then at least mention it in commit message and sent libjpeg-turbo removal for meta-oe.
Sure, Will do that. This patch set was sent in order to get the opinion from everyone. Will send the libjpeg-turbo removal patch to meta-oe once it is accepted in oe-core.
Quoted 58 lines
Quoted 58 lines
[YOCTO #8628]
Signed-off-by Maxin B. John <[email protected]>--- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bbmeta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +40
-0@@ -0,0 +1,40 @@ +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression" +HOMEPAGE = "http://libjpeg-turbo.org/" + +LICENSE = "BSD-3-Clause" +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \ + file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \ + file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \ +" + +DEPENDS = "nasm-native" + +BASEPV = "${@d.getVar('PV',True).split('+')[1]}" + +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz" +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2" +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" + +S = "${WORKDIR}/${BPN}-${BASEPV}" + +# Drop-in replacement for jpeg +PROVIDES = "jpeg" +RPROVIDES_${PN} += "jpeg" +RREPLACES_${PN} += "jpeg" +RCONFLICTS_${PN} += "jpeg" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--with-jpeg8 " + +PACKAGES =+ "jpeg-tools libturbojpeg" + +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality. These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library." +FILES_jpeg-tools = "${bindir}/*" + +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" +INSANE_SKIP_libturbojpeg = "dev-so" + +BBCLASSEXTEND = "native" + +LEAD_SONAME = "libjpeg.so.8"Signature · 1 line
2.4.0
Quoted 8 lines
Quoted 5 lines
Signature · 4 lines
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-coreSignature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Best Regards,
Maxin
Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe
In reply to Maxin B. JohnQuoted 44 lines · Maxin B. John
libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.
[YOCTO #8628]
Signed-off-by Maxin B. John <[email protected]>--- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bbmeta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +1
-0@@ -0,0 +1,40 @@ +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMDinstructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression"
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +4
-0+HOMEPAGE = "http://libjpeg-turbo.org/" + +LICENSE = "BSD-3-Clause" +LIC_FILES_CHKSUM ="file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \
+ file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \
+ file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \
+"meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +8
-0+ +DEPENDS = "nasm-native" + +BASEPV = "${@d.getVar('PV',True).split('+')[1]}" + +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz" +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2" +SRC_URI[sha256sum] ="
4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08"meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +2
-0+ +S = "${WORKDIR}/${BPN}-${BASEPV}"
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb line 28
Quoted 10 lines
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +10
-0+ +# Drop-in replacement for jpeg +PROVIDES = "jpeg" +RPROVIDES_${PN} += "jpeg" +RREPLACES_${PN} += "jpeg" +RCONFLICTS_${PN} += "jpeg" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--with-jpeg8 "
It's true that this is closest to what we currently provide but my understanding of the libjpeg changes is this:
* Both versions 7 and 8 encoders can produce files that are incompatible with decoders of previous versions
* The major additions in 7 and 8 we're never actually accepted at the relevant standards body
* most importantly, my impression is that everyone else is using version 6b (this is also jpeg-turbo upstream default)
I suggest we default to _not_ supporting jpeg8 or jpeg7.
Jussi
+
Quoted 23 lines
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +3
-0+PACKAGES =+ "jpeg-tools libturbojpeg" + +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programsto access libjpeg functionality. These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library."
meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +8
-1+FILES_jpeg-tools = "${bindir}/*" + +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" +INSANE_SKIP_libturbojpeg = "dev-so" + +BBCLASSEXTEND = "native" + +LEAD_SONAME = "libjpeg.so.8" --2.4.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe
In reply to Maxin B. JohnQuoted 2 lines · Maxin B. John
libjpeg-turbo has same API/ABI as libjpeg. It is relatively faster in JPEG compression/decompression than libjpeg.
Please take the libjpeg-turbo 1.4.2 recipe from meta-oe master-next instead of the 1.4.1 recipe from meta-oe master.
Quoted 62 lines
[YOCTO #8628]
Signed-off-by Maxin B. John <[email protected]>--- meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb | 40 ++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 meta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bbmeta/recipes-core/jpeg/libjpeg-turbo_8d+1.4.1.bb new file +40
-1@@ -0,0 +1,40 @@ +DESCRIPTION = "libjpeg-turbo is a derivative of libjpeg that uses SIMD instructions (MMX, SSE2, NEON) to accelerate baseline JPEG compression and decompression" +HOMEPAGE = "http://libjpeg-turbo.org/" + +LICENSE = "BSD-3-Clause" +LIC_FILES_CHKSUM = "file://cdjpeg.h;endline=12;md5=cad955d15145c3fdceec6855e078e953 \ + file://jpeglib.h;endline=14;md5=dfc803dc51ae21178d1376ec73c4454d \ + file://djpeg.c;endline=9;md5=e93a8f2061e8a0ac71c7a485c10489e2 \ +" + +DEPENDS = "nasm-native" + +BASEPV = "${@d.getVar('PV',True).split('+')[1]}" + +SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${BASEPV}.tar.gz" +SRC_URI[md5sum] = "b1f6b84859a16b8ebdcda951fa07c3f2" +SRC_URI[sha256sum] = "4bf5bad4ce85625bffbbd9912211e06790e00fb982b77724af7211034efafb08" + +S = "${WORKDIR}/${BPN}-${BASEPV}" + +# Drop-in replacement for jpeg +PROVIDES = "jpeg" +RPROVIDES_${PN} += "jpeg" +RREPLACES_${PN} += "jpeg" +RCONFLICTS_${PN} += "jpeg" + +inherit autotools pkgconfig + +EXTRA_OECONF = "--with-jpeg8 " + +PACKAGES =+ "jpeg-tools libturbojpeg" + +DESCRIPTION_jpeg-tools = "The jpeg-tools package includes client programs to access libjpeg functionality. These tools allow for the compression, decompression, transformation and display of JPEG files and benchmarking of the libjpeg library." +FILES_jpeg-tools = "${bindir}/*" + +FILES_libturbojpeg = "${libdir}/libturbojpeg.so" +INSANE_SKIP_libturbojpeg = "dev-so" + +BBCLASSEXTEND = "native" + +LEAD_SONAME = "libjpeg.so.8" --2.4.0
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Quoted 9 lines · Maxin B. John
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the libjpeg package to meta-oe for applications which may depend on API version 9.
I support this change, due:
- agreement with major Linux distros
- performance improvement
I also think moving libjpeg (API version 9) for meta-oe is fine as well. I am not aware of any application which requires it, though.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Quoted 11 lines · Otavio Salvador
Quoted 9 lines · Maxin B. John
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the libjpeg package to meta-oe for applications which may depend on API version 9.
Quoted 7 lines
I support this change, due:
- agreement with major Linux distros
- performance improvementI also think moving libjpeg (API version 9) for meta-oe is fine as well. I am not aware of any application which requires it, though.
I'm not aware of any as well, so I would prefer to drop libjpeg completely.
+ less junk in meta-oe
+ people were confused about multiple jpeg providers before, now they would be again, but without good reason (as nobody knows about apps depending on libjpeg9).
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Quoted 20 lines · Martin Jansa
Quoted 11 lines · Otavio Salvador
Quoted 9 lines · Maxin B. John
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the libjpeg package to meta-oe for applications which may depend on API version 9.
Quoted 7 lines
I support this change, due:
- agreement with major Linux distros
- performance improvementI also think moving libjpeg (API version 9) for meta-oe is fine as well. I am not aware of any application which requires it, though.
Quoted 7 lines
I'm not aware of any as well, so I would prefer to drop libjpeg completely.
+ less junk in meta-oe
+ people were confused about multiple jpeg providers before, now they would be again, but without good reason (as nobody knows about apps depending on libjpeg9).
Agreed.
Signature · 3 lines
Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750
Hi,
Quoted 20 lines · Martin Jansa
Quoted 11 lines · Otavio Salvador
Quoted 9 lines · Maxin B. John
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the libjpeg package to meta-oe for applications which may depend on API version 9.
Quoted 7 lines
I support this change, due:
- agreement with major Linux distros
- performance improvementI also think moving libjpeg (API version 9) for meta-oe is fine as well. I am not aware of any application which requires it, though.
Quoted 8 lines
I'm not aware of any as well, so I would prefer to drop libjpeg completely.
+ less junk in meta-oe
+ people were confused about multiple jpeg providers before, now they would be again, but without good reason (as nobody knows about apps depending on libjpeg9).
Agree. In this case, I will send a patch to remove libjpeg-turbo from meta-oe.
Quoted 2 lines
Signature · 1 line
Martin 'JaMa' Jansa jabber: [email protected]
Best Regards,
Maxin
Quoted 20 lines · Martin Jansa
Quoted 11 lines · Otavio Salvador
Quoted 9 lines · Maxin B. John
This patch set provides libjpeg-turbo as a drop-in replacement for libjpeg.
libjpeg-turbo is a fork of the original libjpeg project.Most of the major Linux distros (Fedora, Debian, OpenSUSE) moved from libjpeg to libjpeg-turbo recently. lbjpeg-turbo provides better JPEG compression/decompression(at least 25% faster) while maintaining same API/ABI as libjpeg.
Once we reach an agreement on this, based on the decision, we can move the libjpeg package to meta-oe for applications which may depend on API version 9.
Quoted 7 lines
I support this change, due:
- agreement with major Linux distros
- performance improvementI also think moving libjpeg (API version 9) for meta-oe is fine as well. I am not aware of any application which requires it, though.
Quoted 7 lines
I'm not aware of any as well, so I would prefer to drop libjpeg completely.
+ less junk in meta-oe
+ people were confused about multiple jpeg providers before, now they would be again, but without good reason (as nobody knows about apps depending on libjpeg9).
Indeed, most (read: "I") have set the PREFERRED_SUPPLIER to "jpeg" just to get rid of the warning message, and not really bothering to check what either meant.
I'm in favor of dropping libjpeg completely, it's just confusing.
Moving it will lead to package dependency problems when upgrading from one to the other.
Kind regards,
Mike Looijmans
System Expert
TOPIC Embedded Products Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: [email protected]
Website: www.topicproducts.com
Please consider the environment before printing this e-mail