[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde
Subject:    Re: [kde] Question about KDE 4.2
From:       David Carlos Manuelda <stormbyte () gmail ! com>
Date:       2009-01-07 11:41:57
Message-ID: 200901071241.57319.StormByte () gmail ! com
[Download RAW message or body]

On Tuesday 06 January 2009 21:23:56 Anne Wilson wrote:
> On Tuesday 06 January 2009 17:44:14 Kishore wrote:
> > On Tuesday 06 Jan 2009 10:38:51 pm David Carlos Manuelda wrote:
> > > On Monday 05 January 2009 19:23:39 Nikos Chantziaras wrote:
> > > > Rex Dieter wrote:
> > > > > David Carlos Manuelda wrote:
> > > > >> For example, since I click the K button to raise menu until the
> > > > >> menu is raised, it is a second or two. The same when running
> > > > >> dolphin and clicking in folders for example. I don't note this too
> > > > >> much while running them inside a 3.5.10.
> > > > >
> > > > > I've never seen such operations take more than an instant,
> > > > > regardless of which DE is in use.
> > > > >
> > > > > I would venture there's a different explanation other than the
> > > > > general "kde4 is slower".
> > > >
> > > > This happens if compositing is enabled and a binary-only, proprietary
> > > > NVidia or ATI driver is used or if EXA acceleration is not enabled
> > > > (in the case of open source drivers; the proprietary ones don't
> > > > support EXA.)
> > >
> > > I had compositing disabled, yet using the binary drivers from nvidia so
> > > maybe is EXA related, but is strange, as I said, this does not happens
> > > while running 3.5.10. That's why I asked, because with same X config I
> > > note the impact of performance running the whole kde 4.1.3 over running
> > > same apps inside 3.5.10.
> > > Then, I'll try to set up my X using the VESA driver and retry.
> >
> > As it seems... it does matter. Apparently, KDE4 tends to take full
> > advantage of some underlying features which were barely used before. This
> > supposedly has exposed new bugs in the underlying stuff. This likely does
> > not answer your specific question but was just to give you an idea.
>
> In fact NVidia had to release a new driver for just that reason.  KDE4 was
> using features that had been in the driver for quite a while, but were
> never used.  KDE4 exposed a major weakness that cause unbearably slow
> performance with some NVidia cards.  NVidia acknowledged the problem and
> tackled it.  I suspect we are going to be reaping this sort of problem for
> a while, until all the vendors have come to terms with the new
> requirements.
>
> The good news, though, is that Nikos' solution does seem to be working for
> me.
>
> Anne
>
> Anne

Thanks for the explanation, this answers half of my question but there are 
still a few problems which I don't really know where they come from.
Whe having drawing related issues I understand what is the cause but for 
example, the delay when you click K menu until it is drawn (until, not while) 
for 1 or 2 secs + the delay when you click exit until the "logout window" 
comes up, another 2 secs + the delay when you click some option (reboot, 
logout, shutdown) until it is proccessed, another 2 secs. I can messure this 
because I have the clock plasmoid in taskbar configured to show seconds, and 
in that operations, that clock freezes not updating seconds, so I assume 
something in kdelibs (or in plasma itself) is doing a heavy work.
I can not explain it better, I hope it can be understood.
I confirmed that it does not only happen to me in my system or with my nvidia 
card, and I've been reading lots of stuff in internet of people having this 
issue too so maybe the problem is kdelibs for KDE4 are not still optimized 
(just my idea), and thus, I asked in my first post.
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
[prev in list] [next in list] [prev in thread] [next in thread]