Unity faster than normal?

[ventrical]

Is this for sure ? I mean , is lightdm eats so much ?

Looks like there is no real difference according to system-monitor - a before and after.

*edit*
Actually there is a slight difference when not using lightdm. Why. I don't know. I assume it may be that lightdm is TSR and is hooked to the desktop , or, just perhaps with Unity and not other DEs

At this point I can't really document that Unity *is* actually faster but it appears this way just from response times. I also have another 13.04 install on the same machine with same conditions so my initial post was about the daily image of that day, Friday, and how Unity jumped off the page using the live USB and then subsequently the hard install.

[fjgaude]

Why not run gtkperf? It has always done good by me.

[ventrical]

With lightdm:

GtkPerf 0.40 - Starting testing: Mon Nov 26 04:21:30 2012

GtkEntry - time: 0.10
GtkComboBox - time: 7.80
GtkComboBoxEntry - time: 2.45
GtkSpinButton - time: 0.46
GtkProgressBar - time: 1.03
GtkToggleButton - time: 4.80
GtkCheckButton - time: 0.40
GtkRadioButton - time: 0.64
GtkTextView - Add text - time: 1.90
GtkTextView - Scroll - time: 0.38
GtkDrawingArea - Lines - time: 4.49
GtkDrawingArea - Circles - time: 5.19
GtkDrawingArea - Text - time: 4.25
GtkDrawingArea - Pixbufs - time: 1.30
---
Total time: 35.20
--------------------------------------------------

Without lightdm (startx)
GtkPerf 0.40 - Starting testing: Mon Nov 26 04:27:20 2012

GtkEntry - time: 0.11
GtkComboBox - time: 2.35
GtkComboBoxEntry - time: 1.68
GtkSpinButton - time: 0.20
GtkProgressBar - time: 0.11
GtkToggleButton - time: 0.23
GtkCheckButton - time: 0.15
GtkRadioButton - time: 0.27
GtkTextView - Add text - time: 1.45
GtkTextView - Scroll - time: 0.29
GtkDrawingArea - Lines - time: 4.62
GtkDrawingArea - Circles - time: 4.93
GtkDrawingArea - Text - time: 2.35
GtkDrawingArea - Pixbufs - time: 1.16
---
Total time: 19.91

According to that particular test there is an increase in performance using startx (without lighdm).. so zika is correct.

[zika]

According to that particular test there is an increase in performance using startx (without lighdm).. so zika is correct.

Did You have any doubts...?
Joke aside, I know, that's why I wrote about that. I've been using this for 1.5 testing period... Of course, it has some (even serious) cons (or call them ill-effects) but, I like it...

[jerrylamos]

Try with /usr/bin/ck-launch-session instead if exec, but I do not think it would help...

echo "/usr/bin/ck-launch-session /usr/bin/unity" > ~/.Xsession

Tried that. Oops.

startx
Loading extension GLX
xinit: connection to X server lost

right back to cli. Can't get anywhere.

Tried to start lightdm, got login screen, tried to log in, got login screen, etc. Won't even shut down. Power down, power up, same login screen loop.

Looks like that partition is tanked. Blooey.

So I booted an older partition to enter this message.

I assume the only fix I have to the .Xsession startx attempt is a re-install?

[ventrical]

Did You have any doubts...?
Joke aside, I know, that's why I wrote about that. I've been using this for 1.5 testing period... Of course, it has some (even serious) cons (or call them ill-effects) but, I like it...

Nope .. no doubts at all

Also .. yes .. there are some ill effects using KVM switchers . After I ran those gtkperf test the screen locked and froze .. error or somthing about cannot detect xKeyboard.

[zika]

Nope .. no doubts at all

Also .. yes .. there are some ill effects using KVM switchers . After I ran those gtkperf test the screen locked and froze .. error or somthing about cannot detect xKeyboard.

KVM is not in my system so I can not comment on that. But, I've been honest, that is not a perfect advice, not even a solution, just an option, from a time when I've started trying GnomeShell, OpenBox, FluxBox... It was easier to pin-point troublesome places that way than run around (Li)G(ht)DM...

[ventrical]

KVM is not in my system so I can not comment on that. But, I've been honest, that is not a perfect advice, not even a solution, just an option, from a time when I've started trying GnomeShell, OpenBox, FluxBox... It was easier to pin-point troublesome places that way than run around (Li)G(ht)DM...

I think your advice is great advice for beta testers. Thanks for sharing that method. I am always learning new things here. It's always a phenomenon and a challenge.

Regards,

ventrical

[MG&TL]

I assume the only fix I have to the .Xsession startx attempt is a re-install?

Since I don't have that file on a normal install, I think it's safe to remove it and see if that fixes the problem.

rm ~/.Xsession

[zika]

Tried that. Oops.



right back to cli. Can't get anywhere.

Tried to start lightdm, got login screen, tried to log in, got login screen, etc. Won't even shut down. Power down, power up, same login screen loop.

Looks like that partition is tanked. Blooey.

So I booted an older partition to enter this message.

I assume the only fix I have to the .Xsession startx attempt is a re-install?

Startx with such ~/.Xsession did not tank Your partition as You state... You're just having some problem with X and it showed now... Since You've entered LightDM...
Are You sure that You did not use sudo in trying startx? If You did there is a simple remedy:
remove file ~/.Xauthority ...

Since I don't have that file on a normal install, I think it's safe to remove it and see if that fixes the problem.

rm ~/.Xsession

Yes, that file is not a part of vanilla install. That is why I have without any caution instruct another user to make it... In other case I would (for sure) suggest making a backup...

In my book startx is a nice lacmus(litmus)...