I notice that 3.5.13 takes a long time to exit.
Normally I login from the command line and start X with the startx script. On my 2.3 GHz dual core system with 4GB of RAM and SATA II hard drives, TDE takes about 7 to 8 seconds to exit and more than once I have seen the system take up to 15 to 17 seconds to return to the command line. I do not have sessions enabled, logoff confirmation is disabled, I don't use eye candy, apps are already closed, etc.
My virtual machine takes about 7 to 8 seconds to exit to the command line.
On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard drives, exit time is about 16 seconds. I expect longer times but not that much. Yes, a PII is not a speed demon by any modern standard, and such a system pushes the envelope of "old hardware," but if TDE is targeted for older hardware then the long exit time is not a good marketing point, especially on a dual core system.
The dual core system uses the proprietary Nvidia drivers. The PII uses the tdfx driver and a first generation AGP card.
For the record, 3.5.10 never was a speed demon at exiting either. I just expect more from TDE. :)
There is an enhancement request to provide an option to disable displaying the "Saving your settings" dialog box, but even if implemented, I doubt the dialog box is responsible for the long exit delay.
What could be the cause? Is anybody else experiencing a long exit delay?
Darrell
On 22 December 2011 13:27, Darrell Anderson humanreadable@yahoo.com wrote:
I notice that 3.5.13 takes a long time to exit.
This happens for me too, typically I get sick of it and just power off my machine manually - bug report please!
I wonder what the underlying cause is.
Calvin Morrison
I notice that 3.5.13 takes a long time to exit. This happens for me too, typically I get sick of it and just power off my machine manually - bug report please! I wonder what the underlying cause is.
I'll file a bug report but I first I want to gather some information and comments. Perhaps someobdy has a clue and I can add that information when I file the report. I'm just sharing that my system exits too slow. I don't know whether the problem is TDE, X, my OS or some combination thereof. Thus far I have one user confirmation. :)
I don't want to compare proverbial apples and oranges, but Xfce exits almost immediately. Of course, window managers are even faster to exit. I realize there are some settings to save.
Sometimes I wait for TDE to exit (KDE 3.5.10 too) and just press Ctrl-Alt-Backspace. Generally, TDE always seems slower to exit than KDE. I use both. A second or two is one thing but more than that and the desktop starts to remind me of that "other" operating system. :)
Darrell
I notice that 3.5.13 takes a long time to exit.
Normally I login from the command line and start X with the startx script. On my 2.3 GHz dual core system with 4GB of RAM and SATA II hard drives, TDE takes about 7 to 8 seconds to exit and more than once I have seen the system take up to 15 to 17 seconds to return to the command line. I do not have sessions enabled, logoff confirmation is disabled, I don't use eye candy, apps are already closed, etc.
My virtual machine takes about 7 to 8 seconds to exit to the command line.
On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard drives, exit time is about 16 seconds. I expect longer times but not that much. Yes, a PII is not a speed demon by any modern standard, and such a system pushes the envelope of "old hardware," but if TDE is targeted for older hardware then the long exit time is not a good marketing point, especially on a dual core system.
The dual core system uses the proprietary Nvidia drivers. The PII uses the tdfx driver and a first generation AGP card.
For the record, 3.5.10 never was a speed demon at exiting either. I just expect more from TDE. :)
There is an enhancement request to provide an option to disable displaying the "Saving your settings" dialog box, but even if implemented, I doubt the dialog box is responsible for the long exit delay.
What could be the cause? Is anybody else experiencing a long exit delay?
Darrell
The session manager shutdown is actually a 2 or 3 phase affair, and each phase waits for apps (including kicker, kdesktop, things in your task tray, etc.) to shut down normally before forcibly terminating them. There are several opportunities for delays, and debugging this further will require an instrumented build of tdebase that can profile the delay intoduced by each phase.
This shouldn't be too hard to look at, please file an enhancement bug report.
Tim
On Thu, 22 Dec 2011 14:42:22 -0600 "Timothy Pearson" kb9vqf@pearsoncomputing.net wrote:
I notice that 3.5.13 takes a long time to exit.
Normally I login from the command line and start X with the startx script. On my 2.3 GHz dual core system with 4GB of RAM and SATA II hard drives, TDE takes about 7 to 8 seconds to exit and more than once I have seen the system take up to 15 to 17 seconds to return to the command line. I do not have sessions enabled, logoff confirmation is disabled, I don't use eye candy, apps are already closed, etc.
My virtual machine takes about 7 to 8 seconds to exit to the command line.
On a 350 MHz PII system with 448 MB of RAM and ATA-2 IDE hard drives, exit time is about 16 seconds. I expect longer times but not that much. Yes, a PII is not a speed demon by any modern standard, and such a system pushes the envelope of "old hardware," but if TDE is targeted for older hardware then the long exit time is not a good marketing point, especially on a dual core system.
The dual core system uses the proprietary Nvidia drivers. The PII uses the tdfx driver and a first generation AGP card.
For the record, 3.5.10 never was a speed demon at exiting either. I just expect more from TDE. :)
There is an enhancement request to provide an option to disable displaying the "Saving your settings" dialog box, but even if implemented, I doubt the dialog box is responsible for the long exit delay.
What could be the cause? Is anybody else experiencing a long exit delay?
Darrell
The session manager shutdown is actually a 2 or 3 phase affair, and each phase waits for apps (including kicker, kdesktop, things in your task tray, etc.) to shut down normally before forcibly terminating them. There are several opportunities for delays, and debugging this further will require an instrumented build of tdebase that can profile the delay intoduced by each phase.
This shouldn't be too hard to look at, please file an enhancement bug report.
I took a glance at the code and noticed some timeouts of: -4 seconds for the legacy programs shutdown -10 seconds for the protectionTimer which seems to manage libSM-aware applications If the code is thread-safe it is perhaps possible to encapsulate the performLegacySessionSave() call in a pthread_create/pthread_join, or without it we could give an option to disable the legacy session save like KDE4 does. Speaking of KDE4, I browsed the diff between the KDE 3.5.10 and KDE 4.7.4 ksmservers and found that they have similar shutdown logic so it would be nice to send any improvement patch to the KDE team :) (but regarding the graphical effects KDE4 seems to have much better and MMX/SSE-optimized code)
Tim
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
If you are referring to the shutdown screen fading, it might be a good idea to merge the MMX code into TDE.
Regarding the fadeaway, long ago I wrote a bug report to provide a KControl option to disable the fadeaway. The fadeaway is too slow on older hardware. To me the fadeaway adds no meaningful value but I'm not asking for a complete ripping. :) Lots of people like that kind of eye candy, but we should have an option to disable the effect for those who don't.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=258
Darrell
On Thu, 22 Dec 2011 13:55:06 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
If you are referring to the shutdown screen fading, it might be a good idea to merge the MMX code into TDE.
Regarding the fadeaway, long ago I wrote a bug report to provide a KControl option to disable the fadeaway. The fadeaway is too slow on older hardware. To me the fadeaway adds no meaningful value but I'm not asking for a complete ripping. :) Lots of people like that kind of eye candy, but we should have an option to disable the effect for those who don't.
FYI even your K6-II could take benefit of MMX optimizations.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=258
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
Regarding the fadeaway, long ago I wrote a bug report
to provide a
KControl option to disable the fadeaway. The fadeaway
is too slow on
older hardware. To me the fadeaway adds no meaningful
value but I'm
not asking for a complete ripping. :) Lots of people
like that kind
of eye candy, but we should have an option to disable
the effect for
those who don't.
FYI even your K6-II could take benefit of MMX optimizations.
One of my older machines is a 400 MHz K6-III+ with 256 MB of RAM, but you remember pretty close nonetheless. :)
The other clunker here is a 350 MHz PII. Well, I have a 486 still functioning, but nothing Linux related runs well on that box --- WFWG 3.11 with the Norton Desktop flies. :)
I use those machines as a performance yardstick of sorts for older hardware. Most people today think a 1 GHz machine with 1 GB of RAM is old. Not in this house. :)
Now, do you mean I need to recompile something to take advantage of MMX optimizations or are you referring to something in TDE code that should be tweaked with those optimizations?
Darrell
On Thu, 22 Dec 2011 14:15:25 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
Regarding the fadeaway, long ago I wrote a bug report
to provide a
KControl option to disable the fadeaway. The fadeaway
is too slow on
older hardware. To me the fadeaway adds no meaningful
value but I'm
not asking for a complete ripping. :) Lots of people
like that kind
of eye candy, but we should have an option to disable
the effect for
those who don't.
FYI even your K6-II could take benefit of MMX optimizations.
One of my older machines is a 400 MHz K6-III+ with 256 MB of RAM, but you remember pretty close nonetheless. :)
I confused with the K6-II I used when I was a kid :)
The other clunker here is a 350 MHz PII. Well, I have a 486 still functioning, but nothing Linux related runs well on that box --- WFWG 3.11 with the Norton Desktop flies. :)
are you saying having tried a Linux distribution 15 years younger than your 486... with busybox/uclibc or Slackware 4.0 the performance would probably have been better ;)
I use those machines as a performance yardstick of sorts for older hardware. Most people today think a 1 GHz machine with 1 GB of RAM is old. Not in this house. :)
Not in mine either, such a machine is just "a little slow to use KDE4". Especially with a Full HD panel and KWin effects automatically activated ;) Actually I still have a machine that I could use for KDE4/Trinity optimisation (if I have the time to set up a cross-compiling environment), it's not old (actually it's still in sale today) but has a single-core non-x86 CPU and a very weak GPU which do a good job to slaughter the Debian Squeeze's KDE4 performance.
Now, do you mean I need to recompile something to take advantage of MMX optimizations or are you referring to something in TDE code that should be tweaked with those optimizations?
It is not TDE code yet, but KDE4 code that could be imported into TDE (or alternatively I could implement my own MMX intrisics code...)
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, 22 Dec 2011 13:55:06 -0800 (PST) Darrell Anderson humanreadable@yahoo.com wrote:
If you are referring to the shutdown screen fading, it might be a good idea to merge the MMX code into TDE.
Regarding the fadeaway, long ago I wrote a bug report to provide a KControl option to disable the fadeaway. The fadeaway is too slow on older hardware. To me the fadeaway adds no meaningful value but I'm not asking for a complete ripping. :) Lots of people like that kind of eye candy, but we should have an option to disable the effect for those who don't.
File kdebase/ksmserver/shutdowndlg.cpp:113:
if (KConfigGroup(KGlobal::config(), "Logout").readBoolEntry("doFancyLogout", true))
This seems to refer to a non-existing option; perhaps it existed in the Kubuntu panel...
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
File kdebase/ksmserver/shutdowndlg.cpp:113:
if (KConfigGroup(KGlobal::config(),
"Logout").readBoolEntry("doFancyLogout", true)) This seems to refer to a non-existing option; perhaps it existed in the Kubuntu panel...
Hey! Those settings work! :)
Hmm. My foggy memory seems to recall a long time ago that Tim said feature controls were available in the config file but there was no KControl interface. :)
I took a guess the settings belong in ksmserverrc (how would I actually learn that from the code?). This is what is needed:
[Logout] doFancyLogout=false doFancyLogoutAdditionalDarkness=0.6 doFancyLogoutFadeTime=4000 doFancyLogoutFadeBackTime=1000 doUbuntuLogout=false
Setting doFancyLogout to false does indeed stop the fadeaway effect.
The doFancyLogoutAdditionalDarkness seems to have an upper limit of 1.0. Beyond that and my screen went goofy. The lower limit seems to be 0.0. The entire screen goes black and only a remnant of the kicker panel is still seen.
Playing with doFancyLogoutFadeTime and doFancyLogoutFadeBackTime changes how fast the fadeaway appears and disappears. I don't know the lower and upper limits. I imagine zero is the lower limit as the numbers represent milliseconds.
So seems these settings can be inserted manually. Actually, only doFancyLogout is needed to enable or disable the effect. The other settings could be ignored and the code will use the defaults.
If somebody was to create an interface then I'd think something like this in KDE Components/Session Manager, General section:
All of the following are disabled/ghosted when "Confirm logout" is unchecked. When "Confirm logout" is enabled then the following widget is enabled/unghosted.
* A radio button: Enable fancy gray fadeaway
When that radio button is enabled then the following become enabled/unghosted:
* A slider control from zero to 1.0 for darkness * A slider control from zero to ?? milliseconds for fade time * A slider control from zero to ?? milliseconds for restore time
* If the system is running the Ubuntu OS, then a check box appears, but only if the OS is Ubuntu.
I'll add this information to the bug report!
Darrell
If somebody was to create an interface then I'd think something like this in KDE Components/Session Manager, General section:
All of the following are disabled/ghosted when "Confirm logout" is unchecked. When "Confirm logout" is enabled then the following widget is enabled/unghosted.
- A radio button: Enable fancy gray fadeaway
When that radio button is enabled then the following become enabled/unghosted:
- A slider control from zero to 1.0 for darkness
- A slider control from zero to ?? milliseconds for fade
time
- A slider control from zero to ?? milliseconds for restore
time
- If the system is running the Ubuntu OS, then a check box
appears, but only if the OS is Ubuntu.
Oops. I meant check box, not radio button. :)
Darrell
This shouldn't be too hard to look at, please file an
enhancement bug report.
I took a glance at the code and noticed some timeouts of: -4 seconds for the legacy programs shutdown -10 seconds for the protectionTimer which seems to manage libSM-aware applications If the code is thread-safe it is perhaps possible to encapsulate the performLegacySessionSave() call in a pthread_create/pthread_join, or without it we could give an option to disable the legacy session save like KDE4 does.
Hey hey, now we're talking. :) Perhaps those timeouts explain why occasionally I see longer exit times.
Darrell
The session manager shutdown is actually a 2 or 3 phase affair, and each phase waits for apps (including kicker, kdesktop, things in your task tray, etc.) to shut down normally before forcibly terminating them. There are several opportunities for delays, and debugging this further will require an instrumented build of tdebase that can profile the delay introduced by each phase.
This shouldn't be too hard to look at, please file an enhancement bug report.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=760
We can file additional information when we start troubleshooting, but as a habit I close all apps before exiting. KAlarm, KMix, KwikDisk, Klippy, and Akregator are in my system tray, which must be closed when exiting. I run with one instance of Konqueror preloaded in memory. Most of the kded daemons are running too.
I'm willing to collect data if anybody offers ideas.
Darrell
This shouldn't be too hard to look at, please file an enhancement bug report.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=760
We can file additional information when we start troubleshooting, but as a habit I close all apps before exiting. KAlarm, KMix, KwikDisk, Klippy, and Akregator are in my system tray, which must be closed when exiting. I run with one instance of Konqueror preloaded in memory. Most of the kded daemons are running too.
I added some info to the bug report.
Basically, I see an excessive slow exit if I enable the KDED System Base URL Notifier daemon. With that daemon enabled I see an exit time of about 17 seconds. When disabled I see an exit time of about 7 seconds. Still slow, but better than the other option.In my xsession log I always see the following error:
kdeinit: Got EXEC_NEW 'kconf_update' from launcher
I reported kconf_update as part of the problem in bug report 688 too.
Darrell
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Timothy Pearson