| Summary: | Kopete gets slow or freezes | ||
|---|---|---|---|
| Product: | [Unmaintained] kopete | Reporter: | Andreas Schallenberg <Andreas.Schallenberg> |
| Component: | general | Assignee: | Kopete Developers <kopete-bugs-null> |
| Status: | RESOLVED LATER | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version First Reported In: | 0.11 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
Andreas Schallenberg
2005-12-14 13:07:00 UTC
confirmed in debian packages !! *** Bug 118443 has been marked as a duplicate of this bug. *** I don't see Bug 118443 as a duplicate. This bug is referring to a specific blocking problem. I see the blocking on nearly every action Kopete is doing, independent of the chat style or the display of avatars. It is not a style specific problem but a kopete problem. "nearly every action" means opening new windows (chat, file transfers, pop ups (and therefore user changing their status)), sending messages, changing my status. I have noticed this bug too on KDE 3.5, it is not up to the KDENetwork modules, I have tested and noticed that the bug is either related to KDEPim or KDEBase... Slackware 10.2, Kde 3.5 The bug is not limited to KDE 3.5 but it's getting worse especially for slow machines. Ok I solved the issue when I removed the ~/.fonts directory. Now KDE works with its default Fonts directory, can't tell where it puts the fonts to but it is solved issue... Or it could be that I had 4300 fonts in ~/.fonts/ ... ? [solved] for me the insane amount of fonts is surely the cause, since fontconfig doesn't do well with large sets of fonts. fontconfig will be getting better soon though, as soon as they come out with a new stable release. It cannot be the only reason because I got only 2 additional fonts installed. it is not, I have 0 in there. So it is not solved but hidden again. The problem is not that obvious on fast machines (even though I managed to reproduce it with the abovementioned themes. IMHO, it is a similar problem like the filtering in kmail: lots of blocking operations without the need for it. Do you have the History plugin enabled? If so, do you have the 'show previous x messages' option on? What happens if you turn 'show previous...' off? What happens if you turn History off? TIA Will Yes, I have the history-plugin enabled. Disabling it or not showing previous messages makes the chat window appear immediately again. This seems to be the right direction to look for. it does not on slow machines (btw, slow means 1ghz :( )! It is just masking the real problem because it reduces the time for some actions. It is similar to the filter bug in kmail, for normal filter it does not appear but for calculation intensive like spam checking it does, create a filter with lots of reg exp applied to the whole message and you will see the same problem with this filter, so the problem is not the spam checking even if the error occurs there most. Same applies here. we can reduce the delay by deactivating every notification etc. but the problem will be still there. has anybody tried the 0.12 branch in subversion to see if this goes away with the new styles? > ------- Additional Comments From mattr kde org 2006-02-01 02:04 -------
> has anybody tried the 0.12 branch in subversion to see if this goes away with the new styles?
I've been having some awful performance problems with 0.12, but I
haven't confirmed whether it's kopete's fault - konq is being kinda
laggy too.
it hasn't locked up or crashed, but whenever something important
happens it'll freeze for several seconds - I'll often see a half-drawn
window for whatever it's trying to open. sending and receiving
messages was taking several seconds too, although it seemed to improve
after reopening the chatwindow (which had probably been left open at
least a week).
it's not behaving consistently, though... when I got home and first
tried to do something (10 minutes ago), it took maybe 10 seconds for
kopete to wake up and respond to clicks. right now it seems to be
perfectly fine, no real lag. it'll probably go back to being laggy at
some point...
--
This insane ranting was brought to you by evyl bananas, and the number 3.
www.chani3.com
This should be fixed in 0.12 due to the change in the style engine. If concrete information on how to reproduce can be provided with 0.12, please reopen. |