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 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
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?
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
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
On Thu, Feb 9, 2012 at 12:06 AM, Darrell Anderson humanreadable@yahoo.com wrote:
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?
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
On Thu, Feb 9, 2012 at 12:06 AM, Darrell Anderson humanreadable@yahoo.com wrote:
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?
It currently allows you to select Qt3 or TQt3. Without it the TQt3 port would not have been possible.
Tim
On Sun, Feb 12, 2012 at 12:37 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On Thu, Feb 9, 2012 at 12:06 AM, Darrell Anderson humanreadable@yahoo.com wrote:
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?
It currently allows you to select Qt3 or TQt3. Without it the TQt3 port would not have been possible.
Tim
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.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@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
On Sun, Feb 12, 2012 at 12:37 AM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On Thu, Feb 9, 2012 at 12:06 AM, Darrell Anderson humanreadable@yahoo.com wrote:
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?
It currently allows you to select Qt3 or TQt3. Without it the TQt3 port would not have been possible.
Tim
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 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 :)
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!
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!
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
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
On Sun, 12 Feb 2012 11:12:14 -0800 (PST) Darrell Anderson humanreadable@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.
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
On Sunday 12 February 2012 10:45:22 pm Darrell Anderson 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.
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.
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.
On Sun, 12 Feb 2012 23:09:18 -0500 Kristopher John Gamrat chaotickjg@gmail.com wrote:
On Sunday 12 February 2012 10:45:22 pm Darrell Anderson 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.
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.
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.
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.
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@gmail.com 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.
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.
On Sun, 12 Feb 2012 23:32:04 -0500 Kristopher John Gamrat chaotickjg@gmail.com wrote:
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@gmail.com 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.
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 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 Monday 13 February 2012 12:10:05 am /dev/ammo42 wrote:
On Sun, 12 Feb 2012 23:32:04 -0500 Kristopher John Gamrat chaotickjg@gmail.com wrote:
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.
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.
On Mon, 13 Feb 2012 01:02:19 -0500 Kristopher John Gamrat chaotickjg@gmail.com wrote:
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@gmail.com wrote:
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.
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.
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.
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.
On Sun, 12 Feb 2012 19:45:22 -0800 (PST) Darrell Anderson humanreadable@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.
On Sun, 12 Feb 2012 11:12:14 -0800 (PST) Darrell Anderson humanreadable@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.
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
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
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
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
On Mon, 13 Feb 2012 14:50:42 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
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
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.
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.
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@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 Mon, Feb 13, 2012 at 10:10 PM, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
On Mon, 13 Feb 2012 14:50:42 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
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
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.
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.
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
On Mon, 13 Feb 2012 22:32:40 +0100 Pawel Soltys sh4dou@gmail.com wrote:
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.
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.
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.
<snip>
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...
Sounds good to me! I'll wait for Qt5 then before giving it Qt another serious performance test.
Tim
-
/dev/ammo42 -
Darrell Anderson -
David C. Rankin -
Jonesy -
Kristopher John Gamrat -
Martin Gräßlin -
Pawel Soltys -
Timothy Pearson