All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Otavio Salvador <otavio.salvador@ossystems.com.br>
Cc: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [RFC] Use libjpeg-turbo in place of libjpeg
Date: Fri, 27 Nov 2015 12:19:32 +0100	[thread overview]
Message-ID: <20151127111932.GC17303@jama> (raw)
In-Reply-To: <CAP9ODKq4R9UT2oL_vMALhCA_ocqCSxJoegCa_WEgy0Xj9xFT5A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1294 bytes --]

On Fri, Nov 27, 2015 at 09:13:22AM -0200, Otavio Salvador wrote:
> On Fri, Nov 27, 2015 at 9:04 AM, Maxin B. John <maxin.john@intel.com> wrote:
> > 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.

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).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

  reply	other threads:[~2015-11-27 11:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-27 11:04 [RFC] Use libjpeg-turbo in place of libjpeg Maxin B. John
2015-11-27 11:04 ` [PATCH 1/2] libjpeg: Replace libjpeg with libjpeg-turbo Maxin B. John
2015-11-27 11:04 ` [PATCH 2/2] libjpeg-turbo: import the recipe from meta-oe Maxin B. John
2015-11-27 11:14   ` Martin Jansa
2015-11-27 12:20     ` Maxin B. John
2015-11-27 11:43   ` Jussi Kukkonen
2015-11-27 19:51   ` Andre McCurdy
2015-11-27 11:13 ` [RFC] Use libjpeg-turbo in place of libjpeg Otavio Salvador
2015-11-27 11:19   ` Martin Jansa [this message]
2015-11-27 11:21     ` Otavio Salvador
2015-11-27 12:22     ` Maxin B. John
2015-11-27 13:54     ` Mike Looijmans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151127111932.GC17303@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=otavio.salvador@ossystems.com.br \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.