8 Feb
2012
8 Feb
'12
6:52 p.m.
This should be cleared. Are we going to port trinity to qt4 or don't.
There are users in the IRC channel who ask about this, and I don't
really know how to respond, since it isn't clear to myself.
For what I understood: we won't port trinity to Qt4, we will add
possibility of using qt3 and qt4 together. Is this correct?
8 Feb
8 Feb
8:51 p.m.
New subject: [trinity-devel] Trinity qt4 port?
This should be cleared. Are we going to port trinity
to qt4 or don't.
There are users in the IRC channel who ask about this, and I don't
really know how to respond, since it isn't clear to myself.
For what I understood: we won't port trinity to Qt4, we will add
possibility of using qt3 and qt4 together. Is this correct?
This is correct. At one time there was a desire to port to Qt4, however
months of solid work showed that Qt4 cannot provide the features needed to
create a fast, efficient desktop geared towards mouse/keyboard interaction
and high on-screen information content.
Tim
11:06 p.m.
New subject: [trinity-devel] Trinity qt4 port?
This should be
cleared. Are we
going to port trinity to qt4 or don't.
There are users in the IRC channel who ask about
this,
and I don't
really know how to respond, since it isn't
clear to
myself.
For what I understood: we won't port trinity
to Qt4, we
will add
possibility of using qt3 and qt4 together. Is
this
correct?
This is correct. At one time there was a desire to
port to Qt4, however
months of solid work showed that Qt4 cannot provide the
features needed to
create a fast, efficient desktop geared towards
mouse/keyboard interaction
and high on-screen information content. 
11:41 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Wed, 8 Feb 2012, Darrell Anderson wrote:
As a side comment, in many ways my Windows for Workgroup 3.11 with the
Norton Desktop on my 16 MB 486 machine (still runs!) is faster than any
modern desktop environment. I have that same environment cloned on a PI
class machine and the system screams.
Hardware might improve at 2x the
capacity every 18 months, but software seems to get 2x slower. :)
+1
Every now and then I fire up my old OS/2 WARP 3 machine that I retired
when I moved on to Linux back on 01-01-2000. For a 180 MHZ box, it sure
does not make this dual-core, 2.2 GHZ workstation look like it's really
doing 20x+ -times better performance-wise. :-)
(apologies for the OT topic drift.)
Regards,
Jonesy
--
Marvin L Jones | jonz | W3DHJ | linux
Pueblo, Colorado | @ | Jonesy | OS/2 __
38.238N 104.547W | config.com | DM78rf | SK
11 Feb
11 Feb
11:29 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Thu, Feb 9, 2012 at 12:06 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Okeydokey, but then what is the purpose of TQt?
You mean TQt, which is pretty much the same as Qt3 but with Q* objects
translated to TQ*.
What I'd like to know is purporse of tqtinterface.
Initially I understood it was created to facilitate porting to qt4,
without having to rewrite much of the tdelibs/tdecomponents code. But
now, that there are no plans for Qt4 port, what is it needed for,
except as compilation dependency?
This should be cleared. Are we
going to port
trinity to qt4 or don't.
There are users in the IRC channel who ask about
this,
and I don't
really know how to respond, since it isn't
clear to
myself.
For what I understood: we won't port trinity
to Qt4, we
will add
possibility of using qt3 and qt4 together. Is
this
correct?
This is correct. At one time there was a desire to
port to Qt4, however
months of solid work showed that Qt4 cannot provide the
features needed to
create a fast, efficient desktop geared towards
mouse/keyboard interaction
and high on-screen information content. I would like to see us formally address both questions
in the wiki. I admit I remain confused about the whole picture. :( I would like to see a
good writeup on the wiki discussing the technical details.
In any such public discussion we probably want to qualify your Qt4 observations. I have
no reason to doubt your technical assessment of Qt4, nor am I qualified, but such
statements deserve technical discussion. Possibly some benchmarks too. Otherwise fanboys
and self-appointed nannies will raise a ruckus, regardless of the merits of such
statements. Not that I care about fanatics, but you know the drill. :)>
BTW, I have seen GTK supporters make similar
statements about GTK1 versus GTK2, claiming GTK1 was much faster than GTK2.
As a side comment, in many ways my Windows for Workgroup 3.11 with the Norton Desktop on
my 16 MB 486 machine (still runs!) is faster than any modern desktop environment. I have
that same environment cloned on a PI class machine and the system screams. Hardware might
improve at 2x the capacity every 18 months, but software seems to get 2x slower. :)
Darrell
---------------------------------------------------------------------
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 messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
11:37 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Thu, Feb 9, 2012 at 12:06 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
Okeydokey, but then what is the purpose of TQt?
You mean TQt, which is pretty much the same as Qt3 but with Q* objects
translated to TQ*.
What I'd like to know is purporse of tqtinterface.
Initially I understood it was created to facilitate porting to qt4,
without having to rewrite much of the tdelibs/tdecomponents code. But
now, that there are no plans for Qt4 port, what is it needed for,
except as compilation dependency?
It currently allows you to select Qt3 or TQt3. Without it the TQt3 port
would not have been possible.
Tim
This should be cleared. Are we
going to port
trinity to qt4 or don't.
There are users in the IRC channel who ask about
this,
and I don't
really know how to respond, since it isn't
clear to
myself.
For what I understood: we won't port trinity
to Qt4, we
will add
possibility of using qt3 and qt4 together. Is
this
correct?
This is correct. At one time there was a desire to
port to Qt4, however
months of solid work showed that Qt4 cannot provide the
features needed to
create a fast, efficient desktop geared towards
mouse/keyboard interaction
and high on-screen information content.
11:46 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, Feb 12, 2012 at 12:37 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
Ok, another question: if I use and compile against TQt3, do I still
need tqtinterface? Or can I drop it?
I'm asking it as a packager for archlinux. I'd like to minimize the
dependency chain that is needed to obtain working tdebase.
This is one of the things I don't like about kde4. You need a lot of
(in my opinion) libraries, and underlaying components in order to get
working desktop.
For me, it would be optimal to have only qt3 and tdelibs (+ some minor
things like dbus-tqt) in order to be able build/use tdebase. That
would require some sort of pull-in/replacement of arts (which is my
opinion a strange creation, and should be replaced/segmented at some
point, because it tries to do too many things together) and other
works, which I cannot even image atm, since I'm not familiar with
trinity architecture enough.
On Thu, Feb 9,
2012 at 12:06 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
You mean TQt, which is pretty much the same as Qt3 but with Q* objects
translated to TQ*.
What I'd like to know is purporse of tqtinterface.
Initially I understood it was created to facilitate porting to qt4,
without having to rewrite much of the tdelibs/tdecomponents code. But
now, that there are no plans for Qt4 port, what is it needed for,
except as compilation dependency?
It currently allows you to select Qt3 or TQt3. Without it the TQt3 port
would not have been possible.
Tim
> This
should be cleared. Are we
going to port trinity to qt4 or don't.
> There are users in the IRC channel who ask about this,
and I don't
> really know how to respond, since it isn't clear to
myself.
> For what I understood: we won't port trinity to Qt4, we
will add
> possibility of using qt3 and qt4 together. Is this
correct?
This is correct. At one time there was a desire to
port to Qt4, however
months of solid work showed that Qt4 cannot provide the
features needed to
create a fast, efficient desktop geared towards
mouse/keyboard interaction
and high on-screen information content.
Okeydokey, but then what is the purpose of TQt?
---------------------------------------------------------------------
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 messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
11:50 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, Feb 12, 2012 at 12:37 AM, Timothy Pearson
<kb9vqf(a)pearsoncomputing.net> wrote:
Ok, another question: if I use and compile against TQt3, do I still
need tqtinterface? Or can I drop it?
I'm asking it as a packager for archlinux. I'd like to minimize the
dependency chain that is needed to obtain working tdebase.
This is one of the things I don't like about kde4. You need a lot of
(in my opinion) libraries, and underlaying components in order to get
working desktop.
For me, it would be optimal to have only qt3 and tdelibs (+ some minor
things like dbus-tqt) in order to be able build/use tdebase. That
would require some sort of pull-in/replacement of arts (which is my
opinion a strange creation, and should be replaced/segmented at some
point, because it tries to do too many things together) and other
works, which I cannot even image atm, since I'm not familiar with
trinity architecture enough.
tqtinterface is here to stay. It still abstracts a few niggling problems
with Qt3/TQt3 and provides flexibility when dealing with future Qt3
updates/changes.
Tim
On Thu,
Feb 9, 2012 at 12:06 AM, Darrell Anderson
<humanreadable(a)yahoo.com> wrote:
It currently allows you to select Qt3 or TQt3. Without it the TQt3 port
would not have been possible.
Tim
> > This should be cleared. Are we
> going to port trinity to qt4 or don't.
> > There are users in the IRC channel who ask about this,
> and I don't
> > really know how to respond, since it isn't clear to
> myself.
> > For what I understood: we won't port trinity to Qt4, we
> will add
> > possibility of using qt3 and qt4 together. Is this
> correct?
>
> This is correct. At one time there was a desire to
> port to Qt4, however
> months of solid work showed that Qt4 cannot provide the
> features needed to
> create a fast, efficient desktop geared towards
> mouse/keyboard interaction
> and high on-screen information content.
Okeydokey, but then what is the purpose of TQt?
You mean TQt, which is pretty much the same as Qt3 but with Q* objects
translated to TQ*.
What I'd like to know is purporse of tqtinterface.
Initially I understood it was created to facilitate porting to qt4,
without having to rewrite much of the tdelibs/tdecomponents code. But
now, that there are no plans for Qt4 port, what is it needed for,
except as compilation dependency? 
12 Feb
12 Feb
7:25 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On 02/11/2012 05:50 PM, Timothy Pearson wrote:
tqtinterface is here to stay. It still abstracts a
few niggling problems
with Qt3/TQt3 and provides flexibility when dealing with future Qt3
updates/changes.
Tim
Let me weigh in and add my .02. I don't now, and I have never seen the need to
move to Qt4. I have not found a single thing that Qt3 doesn't provide that
prevents TDE going forward on that toolset. I hate the clumbsy interface Qt4
provides. I have pulled my hair out simply trying to resize the last column
(like in konqueror --profile filemanagement) only to learn that the "far right
column" in any Qt4 implementation cannot be simply resized like it can be in
Qt3. The list of limitations goes on and on.
If Qt4 can be implemented and still look like Qt3, then I don't really mind
(other than the simple frustrations it brings). But if not -- why bother. It is
the trusted look and feel people like about TDE that drives the enthusiasm.
I don't see we save any effort going with Qt4. I truly believe that manpower
required would be less to maintain Qt3 rather than continually shooting at the
moving target Qt4 will provide depending on whatever whim Trolltech has that week.
If it ain't broke -> don't fix it :)
--
David C. Rankin, J.D.,P.E.
7:35 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On 02/12/2012 01:25 AM, David C. Rankin wrote:
I don't see we save any effort going with Qt4. I
truly believe that manpower
required would be less to maintain Qt3 rather than continually shooting at the
moving target Qt4 will provide depending on whatever whim Trolltech has that week.
If it ain't broke -> don't fix it :)
Let me qualify that,
I understand that the Qt4 toolset would make it easier for upstream
application support at sometime in the future. There is nothing wrong with being
able to support (properly) apps built expecting Qt4. I don't know if that could
be accomplished with a minimum "Qt4-runtime" similar to the
"KDE4-runtime"
without having to completely abandon Qt3.
I think a wise project would put out TDE-3.5.13 and work to put out an
alternative TDE-Qt4-3.5.13. I don't think they are mutually exclusive. But I do
believe that a whole sale move to Qt4 would break over half-a-decade of styles
and decorations that currently make Trinity well Trinity :)
Keep up the great work!
--
David C. Rankin, J.D.,P.E.
8:20 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On 02/12/2012 01:25 AM, David C. Rankin wrote:
These are the exact reasons I stopped to the move to Qt4 and picked up
maintinance of Qt3 (now becoming TQt3). I gave the conversion effort my
best shot (which took many, many months of effort) and stopped once it
became apparent how extensive Qt4's limitations were (especially in
drawing operations and native X11 window handling) and also how buggy Qt4
really is.
Thanks for the encouragement!
Tim
I don't see we save any effort going with
Qt4. I truly believe that
manpower
required would be less to maintain Qt3 rather than continually shooting
at the
moving target Qt4 will provide depending on whatever whim Trolltech has
that week.
If it ain't broke -> don't fix it :)
Let me qualify that,
I understand that the Qt4 toolset would make it easier for upstream
application support at sometime in the future. There is nothing wrong with
being
able to support (properly) apps built expecting Qt4. I don't know if that
could
be accomplished with a minimum "Qt4-runtime" similar to the
"KDE4-runtime"
without having to completely abandon Qt3.
I think a wise project would put out TDE-3.5.13 and work to put out an
alternative TDE-Qt4-3.5.13. I don't think they are mutually exclusive. But
I do
believe that a whole sale move to Qt4 would break over half-a-decade of
styles
and decorations that currently make Trinity well Trinity :)
Keep up the great work!
7:12 p.m.
New subject: [trinity-devel] Trinity qt4 port?
These are the exact reasons I stopped to the move to
Qt4 and
picked up
maintenance of Qt3 (now becoming TQt3). I gave the
conversion effort my
best shot (which took many, many months of effort) and
stopped once it
became apparent how extensive Qt4's limitations were
(especially in
drawing operations and native X11 window handling) and also
how buggy Qt4
really is.
An indirect effect of these conversations finally has revealed why porting to Qt4 has not
happened and is not palatable. I'm not qualified to address those issues, but these
past conversations now shed some light.
When viewed from the perspective that Qt4 is (probably) influenced by cell phone design,
then I start to see some of the challenges with Qt4. That does not make Qt4
"right" or "wrong" in itself, but sheds light on whether Qt4 is an
appropriate tool set for the desktop style of computing. Sounds to me that Qt4 is a good
selection for hand-held devices but perhaps not so great for desktop computing.
Thanks for the encouragement!
Please don't let any of the recent conversations discourage you. One person's
opinion is only that --- an opinion. An opinion that is full of holes and false
presumptions. A person who has acted arrogantly and pompously and full of himself. A
person who appointed himself as a nanny and keeper of some self-imagined realm. A person
who, from the beginning of the Trinity project, has voiced nothing but contempt for those
efforts rather than let people choose their own destiny. The essence of free/libre
software is people choose how they want to use software. This person has refused to
embrace that cornerstone and has mocked his own pretense of supporting free/libre
software. The blog post that started these conversations is evidence that this person has
used his own rope to hang himself. Despite his skills, with that post he lost his
credibility.
Tim, regardless of whatever transpires in this list, please know you have my highest
respect as a project leader and skilled software developer. Please continue this journey
with us!
Darrell
13 Feb
13 Feb
3:27 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, 12 Feb 2012 11:12:14 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
When viewed from the perspective that Qt4 is
(probably) influenced by
cell phone design, then I start to see some of the challenges with
Qt4. That does not make Qt4 "right" or "wrong" in itself, but sheds
light on whether Qt4 is an appropriate tool set for the desktop style
of computing. Sounds to me that Qt4 is a good selection for hand-held
devices but perhaps not so great for desktop computing.
Nokia didn't design
Qt4, Trolltech did. Before being bought.
3:45 a.m.
New subject: [trinity-devel] Trinity qt4 port?
When viewed
from the perspective that Qt4 is (probably)
influenced by
cell phone design, then I start to see some of
the
challenges with
Qt4. That does not make Qt4 "right" or
"wrong" in
itself, but sheds
light on whether Qt4 is an appropriate tool set
for the
desktop style
of computing. Sounds to me that Qt4 is a good
selection
for hand-held
devices but perhaps not so great for desktop
computing. Nokia didn't design Qt4, Trolltech did. Before
being
bought.
Aha, my conclusion is incorrect. :)
Looks like Qt4 was around in late 2005:
http://en.wikipedia.org/wiki/Qt_%28framework%29#Current.
Same article, I read the following:
"The next major version of Qt will be Qt 5. It is expected to be released in 2012.
This new version will mark a major change of paradigm in the platform, with
hardware-accelerated graphics...."
I wonder whether than means hardware graphics acceleration will become a requirement to
use Qt5 based apps. The GNOME developers traveled that same road with GNOME 3.
Darrell
4:09 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sunday 12 February 2012 10:45:22 pm Darrell Anderson wrote:
I hope it's not "required", but sure would be a great feature if they made
it "optional". Not all graphics cards have good drivers that enable the hardware
accelerations, and not every Linux user will want to use proprietary ATI/AMD or nVidia
cards (I've not checked the status of the nouveau driver (nor do I care since I'm
not an nVidia user), and I'm not aware of a similar project for ATI/AMD cards).
If they do make it optional, that would be great for game designers (or wannabe game
designers like myself) who want to use Qt for the UI.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
When viewed from the perspective that Qt4 is
(probably)
influenced by
cell phone design, then I start to see some of
the
challenges with
Qt4. That does not make Qt4 "right" or
"wrong" in
itself, but sheds
light on whether Qt4 is an appropriate tool set
for the
desktop style
of computing. Sounds to me that Qt4 is a good
selection
for hand-held
devices but perhaps not so great for desktop
computing. Nokia didn't design Qt4, Trolltech did.
Before being
bought.
Aha, my conclusion is incorrect. :)
Looks like Qt4 was around in late 2005:
http://en.wikipedia.org/wiki/Qt_%28framework%29#Current.
Same article, I read the following:
"The next major version of Qt will be Qt 5. It is expected to be released in 2012.
This new version will mark a major change of paradigm in the platform, with
hardware-accelerated graphics...."
I wonder whether than means hardware graphics acceleration will become a requirement to
use Qt5 based apps. The GNOME developers traveled that same road with GNOME 3.
4:23 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, 12 Feb 2012 23:09:18 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
On Sunday 12 February 2012 10:45:22 pm Darrell
Anderson wrote:
I hope it's not "required", but sure would be a great feature if they
made it "optional". Not all graphics cards have good drivers that
enable the hardware accelerations, and not every Linux user will want
to use proprietary ATI/AMD or nVidia cards (I've not checked the
status of the nouveau driver (nor do I care since I'm not an nVidia
user), and I'm not aware of a similar project for ATI/AMD cards).
There is a
FOSS radeon driver for which some developers at AMD are paid
to work on it, and on my experience it works OK both for light 3D games
and KDE4 compositing (even better than AMD proprietary driver for the
latter). And compared to Intel drivers I've almost never seen it crash.
When viewed from the perspective that Qt4 is
(probably)
influenced by
cell phone design, then I start to see some of
the
challenges with
Qt4. That does not make Qt4 "right" or
"wrong" in
itself, but sheds
light on whether Qt4 is an appropriate tool set
for the
desktop style
of computing. Sounds to me that Qt4 is a good
selection
for hand-held
devices but perhaps not so great for desktop
computing. Nokia didn't design Qt4, Trolltech did.
Before being
bought.
Aha, my conclusion is incorrect. :)
Looks like Qt4 was around in late 2005:
http://en.wikipedia.org/wiki/Qt_%28framework%29#Current.
Same article, I read the following:
"The next major version of Qt will be Qt 5. It is expected to be
released in 2012. This new version will mark a major change of
paradigm in the platform, with hardware-accelerated graphics...."
I wonder whether than means hardware graphics acceleration will
become a requirement to use Qt5 based apps. The GNOME developers
traveled that same road with GNOME 3.
If they do make it optional, that would be great for game designers
(or wannabe game designers like myself) who want to use Qt for the UI.
4:32 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sunday 12 February 2012 11:23:02 pm /dev/ammo42 wrote:
On Sun, 12 Feb 2012 23:09:18 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
I'm using an Intel card right now (same one since December 2009) with the FOSS Intel
driver. I've never seen any crash cause by the driver, all crashes thus far were
either a glitch in some program that overloaded my CPU, or from overheating (though this
usually leads to a kernel panic rather than an X.org crash).
Of course, I rarely run anything that requires 3D acceleration.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
I hope it's not "required", but
sure would be a great feature if they
made it "optional". Not all graphics cards have good drivers that
enable the hardware accelerations, and not every Linux user will want
to use proprietary ATI/AMD or nVidia cards (I've not checked the
status of the nouveau driver (nor do I care since I'm not an nVidia
user), and I'm not aware of a similar project for ATI/AMD cards).
There is a
FOSS radeon driver for which some developers at AMD are paid
to work on it, and on my experience it works OK both for light 3D games
and KDE4 compositing (even better than AMD proprietary driver for the
latter). And compared to Intel drivers I've almost never seen it crash.
5:10 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, 12 Feb 2012 23:32:04 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
On Sunday 12 February 2012 11:23:02 pm /dev/ammo42
wrote:
I have driver
crashes:
-under Slackware 13.1, as soon as I enable KDE 4.4's KWin effects.
(I use Mesa 7.7.1 as 7.8.1 has a severe performance regression with
StepMania)
-under Slackware 13.1, after too many cycles of suspend/resume (highly
variable)
-under Slackware 13.37, when using KDE 4.5 with or without KWin
effects, after at least a half dozen of hours (highly variable)
-under Slackware 13.37, when I play a Xv-accelerated video, then open
an OpenGL game, then close it when the video is still playing (often)
On my AMD laptop, with FOSS drivers, I can simultaneously have KWin
effects, play a video and launch a 3D game without any crash and with
reasonable preformance.
On Sun, 12 Feb 2012 23:09:18 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
I'm using an Intel card right now (same one since December 2009) with
the FOSS Intel driver. I've never seen any crash cause by the driver,
all crashes thus far were either a glitch in some program that
overloaded my CPU, or from overheating (though this usually leads to
a kernel panic rather than an X.org crash).
Of course, I rarely run anything that requires 3D acceleration. I hope it's not "required", but
sure would be a great feature if
they made it "optional". Not all graphics cards have good drivers
that enable the hardware accelerations, and not every Linux user
will want to use proprietary ATI/AMD or nVidia cards (I've not
checked the status of the nouveau driver (nor do I care since I'm
not an nVidia user), and I'm not aware of a similar project for
ATI/AMD cards).
There is a FOSS radeon driver for which some developers at AMD
are
paid to work on it, and on my experience it works OK both for light
3D games and KDE4 compositing (even better than AMD proprietary
driver for the latter). And compared to Intel drivers I've almost
never seen it crash.
6:02 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Monday 13 February 2012 12:10:05 am /dev/ammo42 wrote:
On Sun, 12 Feb 2012 23:32:04 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
I have driver
crashes:
-under Slackware 13.1, as soon as I enable KDE 4.4's KWin effects.
(I use Mesa 7.7.1 as 7.8.1 has a severe performance regression with
StepMania)
-under Slackware 13.1, after too many cycles of suspend/resume (highly
variable)
-under Slackware 13.37, when using KDE 4.5 with or without KWin
effects, after at least a half dozen of hours (highly variable)
-under Slackware 13.37, when I play a Xv-accelerated video, then open
an OpenGL game, then close it when the video is still playing (often)
On my AMD laptop, with FOSS drivers, I can simultaneously have KWin
effects, play a video and launch a 3D game without any crash and with
reasonable preformance.
Have you tried your Intel card on any distro but Slackware? Also, have you tried any
desktop besides KDE4? It might be a glitch in one of the Slackware packages (either a
recompile of the driver or trying on another distro could tell), or one of the glitches in
KDE4 (I seem to remember having a lot of crashes in KDE 4 on several different cards,
though I haven't used it since 4.6 and I hear that 4.8 is supposed to be fairly
stable). I never got around to trying out Slackware, so I wouldn't be able to test the
driver or KDE 4 from within Slackware on my machine.
Purely for comparison purposes, on my Debian Squeeze install, Intel driver, Intel Mobile
Series 4 Integrated Chipset (includes my video card, as is usually the case with Intel):
-I never tried any of the special KWin effects in any KDE version, nor Compiz (never
really cared much for eye-candy)
-I can suspend to RAM and resume countless times without problems aside from impatient
programs that don't want to wait for my network manager to reconnect ;-) (I never
tried suspend to disk)
-I can run my computer full-power almost the entire day without a crash (unless you count
the random crashes the occur if I inadvertently block the fan).
-I've never heard of Xv-accelerated videos before, though on many occasions, I've
had a lot of stuff running at once (including either a DVD or Youtube video) when my
screen saver activates, and a few of those times, it was one of the OpenGL screen savers.
--
Kris Gamrat
Ark Linux webmaster
http://www.arklinux.org/
There is
a FOSS radeon driver for which some developers at AMD are
paid to work on it, and on my experience it works OK both for light
3D games and KDE4 compositing (even better than AMD proprietary
driver for the latter). And compared to Intel drivers I've almost
never seen it crash.
I'm using an Intel card right now (same one since December 2009) with
the FOSS Intel driver. I've never seen any crash cause by the driver,
all crashes thus far were either a glitch in some program that
overloaded my CPU, or from overheating (though this usually leads to
a kernel panic rather than an X.org crash).
Of course, I rarely run anything that requires 3D acceleration.
12:43 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Mon, 13 Feb 2012 01:02:19 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
On Monday 13 February 2012 12:10:05 am /dev/ammo42
wrote:
Actually on Slackware 13.1 I already changed
versions of:
-xf86-video-intel: 2.11.0 to 2.9.1, because 2.11.0 is unusable with
Trinity and KDE 3.5.10
-Mesa: 7.8.1 to 7.7.1 because 7.8.1 has a huge performance regression
with one of the OpenGL games I play
so I know that they are built from pristine sources.
In general Slackware applies very few patches to upstream sources.
On Sun, 12 Feb 2012 23:32:04 -0500
Kristopher John Gamrat <chaotickjg(a)gmail.com> wrote:
I have driver
crashes:
-under Slackware 13.1, as soon as I enable KDE 4.4's KWin effects.
(I use Mesa 7.7.1 as 7.8.1 has a severe performance regression with
StepMania)
-under Slackware 13.1, after too many cycles of suspend/resume
(highly variable)
-under Slackware 13.37, when using KDE 4.5 with or without KWin
effects, after at least a half dozen of hours (highly variable)
-under Slackware 13.37, when I play a Xv-accelerated video, then
open an OpenGL game, then close it when the video is still playing
(often)
On my AMD laptop, with FOSS drivers, I can simultaneously have KWin
effects, play a video and launch a 3D game without any crash and
with reasonable preformance.
Have you tried your Intel card on any distro but Slackware? Also,
have you tried any desktop besides KDE4? It might be a glitch in one
of the Slackware packages (either a recompile of the driver or trying
on another distro could tell), or one of the glitches in KDE4 (I seem
to remember having a lot of crashes in KDE 4 on several different
cards, though I haven't used it since 4.6 and I hear that 4.8 is
supposed to be fairly stable). I never got around to trying out
Slackware, so I wouldn't be able to test the driver or KDE 4 from
within Slackware on my machine. There is
a FOSS radeon driver for which some developers at AMD
are paid to work on it, and on my experience it works OK both
for light 3D games and KDE4 compositing (even better than AMD
proprietary driver for the latter). And compared to Intel
drivers I've almost never seen it crash.
I'm using an Intel card right now (same one since December 2009)
with the FOSS Intel driver. I've never seen any crash cause by
the driver, all crashes thus far were either a glitch in some
program that overloaded my CPU, or from overheating (though this
usually leads to a kernel panic rather than an X.org crash).
Of course, I rarely run anything that requires 3D acceleration.
Purely for comparison purposes, on my Debian Squeeze install, Intel
driver, Intel Mobile Series 4 Integrated Chipset (includes my video
card, as is usually the case with Intel): -I never tried any of the
special KWin effects in any KDE version, nor Compiz (never really
cared much for eye-candy) -I can suspend to RAM and resume countless
times without problems aside from impatient programs that don't want
to wait for my network manager to reconnect ;-) (I never tried
suspend to disk) -I can run my computer full-power almost the entire
day without a crash (unless you count the random crashes the occur if
I inadvertently block the fan). -I've never heard of Xv-accelerated
videos before, though on many occasions, I've had a lot of stuff
running at once (including either a DVD or Youtube video) when my
screen saver activates, and a few of those times, it was one of the
OpenGL screen savers.
Xv is basically the acceleration every video player is using
to rescale
the videos and/or do RGV->YUV conversions.
But apparently you don't have the same generation of Intel hardware
since I have a Core i3.
4:16 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, 12 Feb 2012 19:45:22 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Same article, I read the following:
"The next major version of Qt will be Qt 5. It is expected to be
released in 2012. This new version will mark a major change of
paradigm in the platform, with hardware-accelerated graphics...."
I wonder whether than means hardware graphics acceleration will
become a requirement to use Qt5 based apps. The GNOME developers
traveled that same road with GNOME 3.
Apparently it will:
http://labs.qt.nokia.com/2011/05/11/responses-to-qt-5/
But OTOH GLSL is a high-level language, and llvmpipe enables
compilation from shaders to optimised x86, so doing the rendering with
OpenGL ES shaders rather than custom C++ is not necessarily a big
performance loss even without hardware 3D acceleration (we'll have for
example the advantage that LLVM will target the exact available CPU
features).
GNOME 3 mandatory compositing/OpenGL reportedly already works without
using hardware GPU acceleration:
http://www.phoronix.com/scan.php?page=news_item&px=MTAxMjI
Obviously we'll have to see how it actually works with Qt5.
4:32 a.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sun, 12 Feb 2012 11:12:14 -0800 (PST)
Darrell Anderson <humanreadable(a)yahoo.com> wrote:
I would say that thos information doesn't change the basic argument at
all. It just explains one reason why Nokia bought Qt, to have a toolkit
that would work well on their mobile devices.
Tim
When viewed from the perspective that Qt4 is
(probably) influenced by
cell phone design, then I start to see some of the challenges with
Qt4. That does not make Qt4 "right" or "wrong" in itself, but sheds
light on whether Qt4 is an appropriate tool set for the desktop style
of computing. Sounds to me that Qt4 is a good selection for hand-held
devices but perhaps not so great for desktop computing.
Nokia didn't design
Qt4, Trolltech did. Before being bought. 
8:41 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sunday 12 February 2012 02:20:38 Timothy Pearson wrote:
These are the exact reasons I stopped to the move to
Qt4 and picked up
maintinance of Qt3 (now becoming TQt3). I gave the conversion effort my
best shot (which took many, many months of effort) and stopped once it
became apparent how extensive Qt4's limitations were (especially in
drawing operations and native X11 window handling) and also how buggy Qt4
really is.
May I ask for the benchmarking results? I am seriously interested here
as I
think that I can provide you some valuable help here. My fear is that you had
an incorrect benchmark (the experts call that phoronixing) and that your
decision is because of that on false grounds.
Especially important is to consider that graphics cards, drivers, what you
render (widgets vs scenes), which Qt graphicssystem you use seriously
influences the result. E.g. rendering widgets with raster might be a bad idea.
Cheers
Martin
8:50 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Sunday 12 February 2012 02:20:38 Timothy Pearson
wrote:
I do not have any benchmarks handy at the moment, although this is simply
due to the length of time from those tests to the writing of this message.
The upshot was that Qt4 is significantly slower when it comes to
rendering raster graphics (as you mentioned), and also when large numbers
of widgets are displayed on-screen. If I understand some of the Qt
changes, the raster performance was improved somewhat in the latest
versions of Qt4, but I don't know if the other problems were addressed.
As an aside, 3D graphics hardware is not only expensive, it is also one of
the most proprietary and least-understood components in a typical computer
(it also tends to burn out a lot, at least that is my experience with
anything other than an enterprise-grade nVidia Quadro card). If nVidia
and ATI experienced supply shortages (don't laugh, remember the recent
hard drive scarcity due to flooding in Thailand) I would still need to be
able to use my computers with not-so-great backup graphics hardware, and
possibly without good OpenGL support.
More practically, even slightly sluggish performance is quite noticeable
to power users. Many applications, upon converting from Qt3 to Qt4,
appeared to slow down noticeably.
These are just my $0.02 and experiences in working with Qt 4.7. I am open
to looking at Qt4 again once Trolltech fixes the raster graphics problem
for good.
Tim
These are the exact reasons I stopped to the move
to Qt4 and picked up
maintinance of Qt3 (now becoming TQt3). I gave the conversion effort my
best shot (which took many, many months of effort) and stopped once it
became apparent how extensive Qt4's limitations were (especially in
drawing operations and native X11 window handling) and also how buggy
Qt4
really is.
May I ask for the benchmarking results? I am seriously interested here
as
I
think that I can provide you some valuable help here. My fear is that you
had
an incorrect benchmark (the experts call that phoronixing) and that your
decision is because of that on false grounds.
Especially important is to consider that graphics cards, drivers, what you
render (widgets vs scenes), which Qt graphicssystem you use seriously
influences the result. E.g. rendering widgets with raster might be a bad
idea.
Cheers
Martin
9:10 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Mon, 13 Feb 2012 14:50:42 -0600
"Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote:
Almost all less than 5 years old PC hardware has either a nVidia,
ATI or
Intel GPU, that is not necessarily powerful but definitely has enough
power to render standard controls with OpenGL.
On Sunday 12
February 2012 02:20:38 Timothy Pearson wrote:
I do not have any benchmarks handy at the moment, although this is
simply due to the length of time from those tests to the writing of
this message. The upshot was that Qt4 is significantly slower when it
comes to rendering raster graphics (as you mentioned), and also when
large numbers of widgets are displayed on-screen. If I understand
some of the Qt changes, the raster performance was improved somewhat
in the latest versions of Qt4, but I don't know if the other problems
were addressed.
As an aside, 3D graphics hardware is not only expensive, it is also
one of the most proprietary and least-understood components in a
typical computer (it also tends to burn out a lot, at least that is
my experience with anything other than an enterprise-grade nVidia
Quadro card). If nVidia and ATI experienced supply shortages (don't
laugh, remember the recent hard drive scarcity due to flooding in
Thailand) I would still need to be able to use my computers with
not-so-great backup graphics hardware, and possibly without good
OpenGL support. These are the exact reasons I stopped to the move
to Qt4 and
picked up maintinance of Qt3 (now becoming TQt3). I gave the
conversion effort my best shot (which took many, many months of
effort) and stopped once it became apparent how extensive Qt4's
limitations were (especially in drawing operations and native X11
window handling) and also how buggy Qt4
really is.
May I ask for the benchmarking results? I am seriously interested
here as I
think that I can provide you some valuable help here. My fear is
that you had
an incorrect benchmark (the experts call that phoronixing) and that
your decision is because of that on false grounds.
Especially important is to consider that graphics cards, drivers,
what you render (widgets vs scenes), which Qt graphicssystem you
use seriously influences the result. E.g. rendering widgets with
raster might be a bad idea.
Cheers
Martin
More practically, even slightly sluggish performance is quite
noticeable to power users. Many applications, upon converting from
Qt3 to Qt4, appeared to slow down noticeably.
Even with a common Qt-internal style
such as CDE or Win9x ?
These are just my $0.02 and experiences in working with Qt 4.7. I am
open to looking at Qt4 again once Trolltech fixes the raster graphics
problem for good.
It will be "fixed" with Qt5, which will have OpenGL ES
2.0 as the only
graphics system. It had better work well with llvmpipe...
Tim
---------------------------------------------------------------------
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
9:32 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Mon, Feb 13, 2012 at 10:10 PM, /dev/ammo42
<mickeytintincolle(a)yahoo.fr> wrote:
On Mon, 13 Feb 2012 14:50:42 -0600
"Timothy Pearson" <kb9vqf(a)pearsoncomputing.net> wrote:
Almost all less than 5 years old PC hardware has either a nVidia,
ATI or
Intel GPU, that is not necessarily powerful but definitely has enough
power to render standard controls with OpenGL.
>
Please take a note that there are places on earth, where people use
computers older that 5 years old, simply because they cannot (don't
have means, like money) to upgrade them.
Once linux was considered as a system that could be installed and used
on nearly antic computers. I remember my friend installing it on a PC
that come form 1996, and turning it to fully functional computer that
needed only allow internet access and document handling. It was in
2004 or 2004. I don't really remember what he had installed there, but
probably it was some old (2.x) version of KDE. He ended up with fully
functional PC that a non-expert user (actually his mother, which
couldn't distinguish between PC and monitor) could use it. Right now,
I don't find it possible without need to use a software that only
experienced linux user could use/configure.
If we are to introduce software that demands bu default more and more
powerful hardware, we do nothing other that taking away the
possibility of comfortable usage of computer for those that cannot
obtain modern(ish) computers, and we do what closed-source companies
(I don't want to throw names, but all of you can imagine what I'm
taking about) were doing for years: forcing updates of hardware with
every new version of the software.
On Sunday
12 February 2012 02:20:38 Timothy Pearson wrote:
I do not have any benchmarks handy at the moment, although this is
simply due to the length of time from those tests to the writing of
this message. The upshot was that Qt4 is significantly slower when it
comes to rendering raster graphics (as you mentioned), and also when
large numbers of widgets are displayed on-screen. If I understand
some of the Qt changes, the raster performance was improved somewhat
in the latest versions of Qt4, but I don't know if the other problems
were addressed.
As an aside, 3D graphics hardware is not only expensive, it is also
one of the most proprietary and least-understood components in a
typical computer (it also tends to burn out a lot, at least that is
my experience with anything other than an enterprise-grade nVidia
Quadro card). If nVidia and ATI experienced supply shortages (don't
laugh, remember the recent hard drive scarcity due to flooding in
Thailand) I would still need to be able to use my computers with
not-so-great backup graphics hardware, and possibly without good
OpenGL support. These are the exact reasons I stopped to the move
to Qt4 and
picked up maintinance of Qt3 (now becoming TQt3). I gave the
conversion effort my best shot (which took many, many months of
effort) and stopped once it became apparent how extensive Qt4's
limitations were (especially in drawing operations and native X11
window handling) and also how buggy Qt4
really is.
May I ask for the benchmarking results? I am seriously interested
here as I
think that I can provide you some valuable help here. My fear is
that you had
an incorrect benchmark (the experts call that phoronixing) and that
your decision is because of that on false grounds.
Especially important is to consider that graphics cards, drivers,
what you render (widgets vs scenes), which Qt graphicssystem you
use seriously influences the result. E.g. rendering widgets with
raster might be a bad idea.
Cheers
Martin More
practically, even slightly sluggish performance is quite
noticeable to power users. Many applications, upon converting from
Qt3 to Qt4, appeared to slow down noticeably.
Even with a common Qt-internal style
such as CDE or Win9x ?
These are just my $0.02 and experiences in working with Qt 4.7. I am
open to looking at Qt4 again once Trolltech fixes the raster graphics
problem for good.
It will be "fixed" with Qt5, which will have OpenGL ES
2.0 as the only
graphics system. It had better work well with llvmpipe...
>
> Tim
10:02 p.m.
New subject: [trinity-devel] Trinity qt4 port?
On Mon, 13 Feb 2012 22:32:40 +0100
Pawel Soltys <sh4dou(a)gmail.com> wrote:
Please take a note that there are places on earth, where people use
computers older that 5 years old, simply because they cannot (don't
have means, like money) to upgrade them. I know that, having begun to use Linux on
2006 with an AMD K6-II box
on which Mandr{ake,iva}'s KDE3 was too slow to be useful ;)
And the 5 years old is probably conservative considering older hardware
that had decent ATI/nVidia hardware, but I didn't want to include Intel
8xx "Graphics My A**" AGP chipsets on which even Extreme Tux Racer has
the performance of a snail. Still I was talking about HW-accelerated
widget rendering, not current KDE4. KDE4 will run even on Intel 8xx
systems.
As an aside, 3D graphics hardware is not only
expensive, it is also
one of the most proprietary and least-understood components in a
typical computer (it also tends to burn out a lot, at least that is
my experience with anything other than an enterprise-grade nVidia
Quadro card). If nVidia and ATI experienced supply shortages
(don't laugh, remember the recent hard drive scarcity due to
flooding in Thailand) I would still need to be able to use my
computers with not-so-great backup graphics hardware, and possibly
without good OpenGL support.
Almost all less than 5 years old PC hardware has
either a nVidia,
ATI or Intel GPU, that is not necessarily powerful but definitely
has enough power to render standard controls with OpenGL. Once linux was considered as a system that could be
installed and used
on nearly antic computers. I remember my friend installing it on a PC
that come form 1996, and turning it to fully functional computer that
needed only allow internet access and document handling. It was in
2004 or 2004. I don't really remember what he had installed there, but
probably it was some old (2.x) version of KDE. He ended up with fully
functional PC that a non-expert user (actually his mother, which
couldn't distinguish between PC and monitor) could use it. Right now,
I don't find it possible without need to use a software that only
experienced linux user could use/configure.
One year ago a not-expert-at-all
relative of mine was still using, for
business, a box of which the newest component was a Radeon 9550 (the
rest being from 2000-2001). And still, with just a RAM upgrade
(256M->768M) it runs Xfce4 and KDE3 well (even with Flash and
many tabs of Firefox on them...). KDE4 also runs on it, the performance
is not stellar but still good enough to do useful things. The KDE4
distribution I tested being released 10 years after the motherboard,
I'd call it good :)
If we are to introduce software that demands bu
default more and more
powerful hardware, we do nothing other that taking away the
possibility of comfortable usage of computer for those that cannot
obtain modern(ish) computers, and we do what closed-source companies
(I don't want to throw names, but all of you can imagine what I'm
taking about) were doing for years: forcing updates of hardware with
every new version of the software.
And still KDE4 works well on hardware on which
Winblows 7 has no
graphics drivers because the manufacturer doesn't care about it any
more.
9:35 p.m.
New subject: [trinity-devel] Trinity qt4 port?
<snip>
Sounds good to me! I'll wait for Qt5 then before giving it Qt another
serious performance test.
Tim
Almost all less than 5 years old PC hardware has
either a nVidia, ATI or
Intel GPU, that is not necessarily powerful but definitely has enough
power to render standard controls with OpenGL.
I was testing Qt4 on an Intel graphics system and it still seemed
sluggish. :-) Another area of concern is with remote desktops (e.g. thin
clients); how will rendering be handled in that case? Will we need to
have Chromium (the GL renderer and stream processor, not the browser)
developed and installed to make things work?
More
practically, even slightly sluggish performance is quite
noticeable to power users. Many applications, upon converting from
Qt3 to Qt4, appeared to slow down noticeably.
Even with a common Qt-internal style
such as CDE or Win9x ?
These are just my $0.02 and experiences in working with Qt 4.7. I am
open to looking at Qt4 again once Trolltech fixes the raster graphics
problem for good.
It will be "fixed" with Qt5, which will have OpenGL ES
2.0 as the only
graphics system. It had better work well with llvmpipe...
4729
days inactive
4734
days old
27 comments
8 participants
participants (8)
-
/dev/ammo42 -
Darrell Anderson -
David C. Rankin -
Jonesy -
Kristopher John Gamrat -
Martin Gräßlin -
Pawel Soltys -
Timothy Pearson