All,
Is there any reason not to use libjpeg-turbo instead of libjpeg when building tde? Why not benefit from the acceleration?
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
On 02/21/2012 02:49 PM, Timothy Pearson wrote:
All,
Is there any reason not to use libjpeg-turbo instead of libjpeg whenbuilding 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
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 :)
On 21 February 2012 16:33, David C. Rankin drankinatty@suddenlinkmail.com 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.
Tim
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
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?
On 21 February 2012 17:14, David C. Rankin drankinatty@suddenlinkmail.com wrote:
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:
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
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
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 whenbuilding 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?
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
On 21 February 2012 16:51, Darrell Anderson humanreadable@yahoo.com wrote:
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
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
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 libjpegwhen
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?
It seems to require multilib, and I don't want to get into repackaging it (due to my perpetual lack of time).
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 it's build on x86, since anything compiled on there is basically "monolib" anyway.
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 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 Tuesday 21 February 2012 05:12:16 pm Timothy Pearson wrote:
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 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.
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.
On Tuesday 21 February 2012 05:12:16 pm Timothy Pearson wrote:
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
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.
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
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
On Tuesday 21 February 2012 04:54:51 pm Calvin Morrison wrote:
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.
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 :-)
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.
On 21 February 2012 15:50, Serghei Amelian serghei@thel.ro wrote:
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.
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
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
Kristopher John Gamrat -
Serghei Amelian -
Timothy Pearson