22 Feb
2012
22 Feb
'12
3:45 a.m.
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when
building tde? Why not benefit from the acceleration?
--
David C. Rankin, J.D.,P.E.
22 Feb
22 Feb
3:49 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when
building tde? Why not benefit from the acceleration?
--
David C. Rankin, J.D.,P.E.
I would recommend using it actually. It makes quite a difference in the
VNC applications; I can watch OTA HD TV at several FPS over VNC with it (I
know, not really watchable, but still impressive given the overall
inefficiency of the VNC protocol).
The only reason I haven't compiled into Ubuntu < Oneiric is that it is
only available as a package in Oneiric and up.
Tim
4:33 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On 02/21/2012 02:49 PM, Timothy Pearson wrote:
That's what I thought. When I originally did the Arch build scripts for
trinity I had libjpeg-turbo as the dependency, but the current scripts in
tde-packaging use libjpeg. I've updated my set to use libjpeg-turbo and am
recompiling Qt3 as we speak. I'll update the Arch scripts in tde-packaging as
soon as I figure out how to do it :) (it took about 5 minutes to figure out
svn, I'm sure it's the same for git :)
--
David C. Rankin, J.D.,P.E.
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when
building tde? Why not benefit from the acceleration?
--
David C. Rankin, J.D.,P.E.
I would recommend using it actually. It makes quite a difference in the
VNC applications; I can watch OTA HD TV at several FPS over VNC with it (I
know, not really watchable, but still impressive given the overall
inefficiency of the VNC protocol).
The only reason I haven't compiled into Ubuntu< Oneiric is that it is
only available as a package in Oneiric and up.
Tim
4:39 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On 21 February 2012 16:33, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
On 02/21/2012 02:49 PM, Timothy Pearson wrote:
That's what I thought. When I originally did the Arch build scripts for
trinity I had libjpeg-turbo as the dependency, but the current scripts in
tde-packaging use libjpeg. I've updated my set to use libjpeg-turbo and am
recompiling Qt3 as we speak. I'll update the Arch scripts in tde-packaging
as soon as I figure out how to do it :) (it took about 5 minutes to figure
out svn, I'm sure it's the same for git :)
--
David C. Rankin, J.D.,P.E.
It uses libjpeg as a dependency because libjpeg is provided by
libjpeg-turbo. it should compile fine either way
Calvin
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when
building tde? Why not benefit from the acceleration?
--
David C. Rankin, J.D.,P.E.
I would recommend using it actually. It makes quite a difference in the
VNC applications; I can watch OTA HD TV at several FPS over VNC with it (I
know, not really watchable, but still impressive given the overall
inefficiency of the VNC protocol).
The only reason I haven't compiled into Ubuntu< Oneiric is that it is
only available as a package in Oneiric and up.
Tim
5:14 a.m.
New subject: Arch tde-packaging was [Re: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?]
On 02/21/2012 03:39 PM, Calvin Morrison wrote:
It uses libjpeg as a dependency because libjpeg is provided by
libjpeg-turbo. it should compile fine either way
Calvin
Calvin,
I am preparing pkgbuild scripts that can be used to pull and build directly
from git. Do you have any preference on how you want to layout the arch
tde-packaging repo to distinguish this? Currently the scripts build from
tarballs made from git and some include path references to
dependencies/tqtinterface, etc.. instead of just tqtinterface. I have been
cleaning that up as I go along as well as cleaning up the
url="pearsoncomputing..." information. Eg:
url="http://scm.trinitydesktop.org/scm/git/qt3"
Currently the git repository has:
tde-packaging/
tde-packaging/arch/
tde-packaging/arch/3.5.13/
tde-packaging/arch/3.5.13_broken/
tde-packaging/arch/extras/
I was thinking about putting the sources that use git in:
tde-packaging/arch/git
What do you think? Also, how do you want to handle standardizing the
pkgbuild path reference information? When I create tarballs, I only keep the
needed path information for the files in the tarball. Eg:
qt3/
and not
dependencies/qt3
Obviously, I cannot update the existing files in 3.5.13 with anything I've
done as a result. I was hoping we could figure out what we want to do for Arch
and standardize this. I could modify the file that creates the tarballs to
include the extra directory information, but that requires that every PKGBUILD
have that information hardcoded into it: Eg:
cd ${srcdir}/dependencies/${pkgname}
instead of just the standard
cd ${srcdir}/${pkgname}
I think it makes sense to standardize the tarballs in a way that we don't
have to worry about custom paths in the PKGBUILD files.
What do you think?
--
David C. Rankin, J.D.,P.E.
5:47 a.m.
New subject: [trinity-devel] Arch tde-packaging was [Re: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?]
On 21 February 2012 17:14, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
On 02/21/2012 03:39 PM, Calvin Morrison wrote:
there is a folder called git. I think that is suitable.
Otherwise we could start using a branch to do it.
Either way
I am also okay with anyone using
It uses libjpeg as a dependency because libjpeg is provided by
libjpeg-turbo. it should compile fine either way
Calvin
Calvin,
I am preparing pkgbuild scripts that can be used to pull and build directly
from git. Do you have any preference on how you want to layout the arch
tde-packaging repo to distinguish this? Currently the scripts build from
tarballs made from git and some include path references to
dependencies/tqtinterface, etc.. instead of just tqtinterface. I have been
cleaning that up as I go along as well as cleaning up the
url="pearsoncomputing..." information. Eg:
url="http://scm.trinitydesktop.org/scm/git/qt3"
Currently the git repository has:
tde-packaging/
tde-packaging/arch/
tde-packaging/arch/3.5.13/
tde-packaging/arch/3.5.13_broken/
tde-packaging/arch/extras/
I was thinking about putting the sources that use git in:
tde-packaging/arch/git
What do you think? Also, how do you want to handle standardizing the
pkgbuild path reference information? When I create tarballs, I only keep the
needed path information for the files in the tarball. Eg:
qt3/
and not
dependencies/qt3
Obviously, I cannot update the existing files in 3.5.13 with anything I've
done as a result. I was hoping we could figure out what we want to do for
Arch and standardize this. I could modify the file that creates the tarballs
to include the extra directory information, but that requires that every
PKGBUILD have that information hardcoded into it: Eg:
cd ${srcdir}/dependencies/${pkgname}
instead of just the standard
cd ${srcdir}/${pkgname}
I think it makes sense to standardize the tarballs in a way that we don't
have to worry about custom paths in the PKGBUILD files.
What do you think?
--
David C. Rankin, J.D.,P.E.
---------------------------------------------------------------------
To unsubscribe, e-mail: trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
4:44 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 04:33:12 pm David C. Rankin wrote:
On 02/21/2012 02:49 PM, Timothy Pearson wrote:
>> All,
>>
>> Is there any reason not to use libjpeg-turbo instead of libjpeg when
>> building tde? Why not benefit from the acceleration?
>>
>> --
>> David C. Rankin, J.D.,P.E.
>
> I would recommend using it actually. It makes quite a difference in the
> VNC applications; I can watch OTA HD TV at several FPS over VNC with it (I
> know, not really watchable, but still impressive given the overall
> inefficiency of the VNC protocol).
>
> The only reason I haven't compiled into Ubuntu< Oneiric is that it is
> only available as a package in Oneiric and up.
As long as it doesn't introduce any issues, and as long as it can coexist with normal
libjpeg, why not compile a version for TDE just for the distros/versions that don't
already have it?
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
4:51 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
As long as it doesn't introduce any issues, and as
long as
it can coexist with normal libjpeg, why not compile a
version for TDE just for the distros/versions that don't
already have it?
We should not repackage anything still actively maintained upstream and is not a direct
dependency for Trinity.
Serghei said he would add a detection test to the cmake files.
One note: if packagers build with libjpeg-turbo installed but downstream users do not have
libjpeg-turbo installed, everything should still work. That is, using libjpeg-turbo should
be optional in the code but still use the expected default libjpeg libraries when
libjpeg-turbo is not installed.
Darrell
4:59 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On 21 February 2012 16:51, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
it doesn't matter, libjpeg-turbo replaces it. the API the same, code
won't break... it's sort of an drop in replacement.:)
Calvin
As long as it
doesn't introduce any issues, and as long as
it can coexist with normal libjpeg, why not compile a
version for TDE just for the distros/versions that don't
already have it?
We should not repackage anything still actively maintained upstream and is not a direct
dependency for Trinity.
Serghei said he would add a detection test to the cmake files.
One note: if packagers build with libjpeg-turbo installed but downstream users do not
have libjpeg-turbo installed, everything should still work. That is, using libjpeg-turbo
should be optional in the code but still use the expected default libjpeg libraries when
libjpeg-turbo is not installed.
Darrell
4:51 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 04:33:12 pm David C.
Rankin wrote:
It seems to require multilib, and I don't want to get into repackaging it
(due to my perpetual lack of time).
Tim
On 02/21/2012 02:49 PM, Timothy Pearson wrote:
the
As long as it doesn't introduce any issues, and as long as it can coexist
with normal libjpeg, why not compile a version for TDE just for the
distros/versions that don't already have it?
> All,
>
> Is there any reason not to use libjpeg-turbo instead of libjpeg
when
building
tde? Why not benefit from the acceleration?
--
David C. Rankin, J.D.,P.E.
I would recommend using it actually. It makes quite a difference in VNC applications; I can watch OTA HD TV at
several FPS over VNC with
it (I
> know, not really watchable, but still impressive given the overall
> inefficiency of the VNC protocol).
>
> The only reason I haven't compiled into Ubuntu< Oneiric is that it is
> only available as a package in Oneiric and up.
5:02 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 04:51:26 pm Timothy Pearson wrote:
It seems to require multilib, and I don't want to get into repackaging it
(due to my perpetual lack of time).
I meant starting with R14 :-)
I've never heard of something requiring multilib, nor should it if it's build on
x86, since anything compiled on there is basically "monolib" anyway.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
On 02/21/2012 02:49 PM, Timothy Pearson wrote:
> The only reason I haven't compiled into Ubuntu< Oneiric is that it is
> only available as a package in Oneiric and up.
As long as it doesn't introduce any issues, and as long as it can coexist
with normal libjpeg, why not compile a version for TDE just for the
distros/versions that don't already have it?
5:12 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 04:51:26 pm Timothy
Pearson wrote:
coexist
I meant starting with R14 :-)
I've never heard of something requiring multilib, nor should it if it's
build on x86, since anything compiled on there is basically "monolib"
anyway.
The way they did the libturbo packages ensures that they won't build on
anything less than oneiric. All I know is that it relies on the
/usr/lib-<archname>/ structure.
Tim
> On
02/21/2012 02:49 PM, Timothy Pearson wrote:
> > The only reason I haven't compiled into Ubuntu< Oneiric is that it
is
> only
available as a package in Oneiric and up.
As long as it doesn't introduce any issues, and as long as it can with normal libjpeg, why not compile a version
for TDE just for the
distros/versions that don't already have it?
It seems to require multilib, and I don't want to get into repackaging
it
(due to my perpetual lack of time).
5:16 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 05:12:16 pm Timothy Pearson wrote:
If that's just the Ubuntu package of libjpeg-turbo (not the normal libjpeg-turbo),
that makes more sense. I've seen quite a few things in Ubuntu where I couldn't
figure out their reasoning.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
On Tuesday 21
February 2012 04:51:26 pm Timothy Pearson wrote:
I meant starting with R14 :-)
I've never heard of something requiring multilib, nor should it if it's
build on x86, since anything compiled on there is basically "monolib"
anyway.
The way they did the libturbo packages ensures that they won't build on
anything less than oneiric. All I know is that it relies on the
/usr/lib-<archname>/ structure. > On
02/21/2012 02:49 PM, Timothy Pearson wrote:
> > The only reason I haven't compiled into Ubuntu< Oneiric is that it
is
> > only available as a package in Oneiric
and up.
As long as it doesn't introduce any issues, and as long as it can
coexist
with normal libjpeg, why not compile a version
for TDE just for the
distros/versions that don't already have it?
It seems to require multilib, and I don't want to get into repackaging
it
(due to my perpetual lack of time).
5:23 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 05:12:16 pm Timothy
Pearson wrote:
it's
If that's just the Ubuntu package of libjpeg-turbo (not the normal
libjpeg-turbo), that makes more sense. I've seen quite a few things in
Ubuntu where I couldn't figure out their reasoning.
Yes, the Ubuntu package is what I am referring to. Sorry if I was not
clear. :-)
TDE will detect if the libjpeg-turbo package is available on Ubuntu/Debian
and compile against it if it is.
Tim
On
Tuesday 21 February 2012 04:51:26 pm Timothy Pearson wrote:
> >> On 02/21/2012 02:49 PM, Timothy Pearson wrote:
> >> > The only reason I haven't compiled into Ubuntu< Oneiric is that
it
> is
> >> > only available as a package in Oneiric and up.
> >
> > As long as it doesn't introduce any issues, and as long as it can
> coexist
> > with normal libjpeg, why not compile a version for TDE just for the
> > distros/versions that don't already have it?
> >
>
> It seems to require multilib, and I don't want to get into
repackaging
it
(due to my perpetual lack of time).
I meant starting with R14 :-)
I've never heard of something requiring multilib, nor should it if build on x86, since anything compiled on there is
basically "monolib"
anyway.
The way they did the libturbo packages ensures that they won't build on
anything less than oneiric. All I know is that it relies on the
/usr/lib-<archname>/ structure.
4:54 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
As long as it doesn't introduce any issues, and as
long as it can coexist with normal libjpeg, why not compile a version for TDE just for the
distros/versions that don't already have it?
Seems like a lot of work for little gain. Ubuntu developers should be
updating their repositories to the latest and greatest libjpeg fork,
not us.
Enough is already on the plate
Cal
5:07 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 04:54:51 pm Calvin Morrison wrote:
If newer versions of Ubuntu are using libjpeg-turbo, why not? I'm certainly not
suggesting that we do something to increase the work load, but unless dpkg build scripts
are really that hard to work with (or if they don't support downloading source
archives during the build process, e.g. they require the package builder to download
beforehand), it shouldn't be that hard to simply update the package version in the
build script when queueing up the next release on the build server :-)
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
As long as it
doesn't introduce any issues, and as long as it can coexist with normal libjpeg, why
not compile a version for TDE just for the distros/versions that don't already have
it?
Seems like a lot of work for little gain. Ubuntu developers should be
updating their repositories to the latest and greatest libjpeg fork,
not us. 
3:50 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On Tuesday 21 February 2012 22:45:51 David C. Rankin wrote:
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when
building tde? Why not benefit from the acceleration?
No reason :) When I will have some free time I will patch cmake to detect and
use it.
--
Serghei.
3:57 a.m.
New subject: [trinity-devel] Any reason NOT to use libjpeg-turbo instead of libjpeg?
On 21 February 2012 15:50, Serghei Amelian <serghei(a)thel.ro> wrote:
On Tuesday 21 February 2012 22:45:51 David C. Rankin
wrote:
Some time ago archlinux started doing this as default AFAIK.
http://www.archlinux.org/packages/extra/x86_64/libjpeg-turbo/
Calvin
For us it is automatically detecting it already I think
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when
building tde? Why not benefit from the acceleration?
No reason :) When I will have some free time I will patch cmake to detect and
use it.
--
Serghei.
4729
days inactive
4729
days old
17 comments
6 participants
participants (6)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Kristopher John Gamrat -
Serghei Amelian -
Timothy Pearson