On Wednesday 07 January 2009 12:41:57 David Carlos Manuelda wrote:
> 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.
Or.. maybe the problem come from QT4 too? I am not an expert so I can't really
tell but something really weird is happening here, as you said
the 'underlaying' software, that could include also QT4.
___________________________________________________
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.
