Bug 146839

Summary:	Konqueror is sometimes very slow on some pages - something X related
Product:	[Applications] konqueror	Reporter:	Sami Liedes <sami.liedes>
Component:	khtml	Assignee:	Konqueror Developers <konq-bugs>
Status:	RESOLVED UNMAINTAINED
Severity:	normal	CC:	kmm
Priority:	NOR
Version:	3.5
Target Milestone:	---
Platform:	Debian testing
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Sami Liedes 2007-06-16 02:41:27 UTC

Version:            (using KDE KDE 3.5.7)
Installed from:    Debian testing/unstable Packages

Sometimes X uses very much resources when scrolling or redrawing pages in Konqueror. I have not found a sure way to reproduce this, but for example right now this is true for this window where I am reporting this bug. It might also be an X bug (ie. something is too slow in X instead of Konqueror doing too much something), but since it manifests itself with Konqueror, it seems like the natural first suspect.

I use the free (as in speech) ati driver from the Debian package xserver-xorg-video-ati 1:6.6.3-2 on xserver-xorg 2:1.3.0.0.dfsg-6. I don't know if other cards/drivers are affected.

When I stress Konqueror and profile, most of the time gets spent in /usr/lib/xorg/modules/libfb.so in a function named fbCopyAreammx(). Obviously this suggests a lot of copying/blitting is happening. Sometimes time is spent in different functions in the same file, but I forgot which one and don't seem able to reproduce that just now anymore...

Comment 1 Sami Liedes 2007-06-16 03:05:33 UTC

Probably related to #29138.

Comment 2 Maksim Orlovich 2007-06-16 04:07:59 UTC

That's pretty odd that it's happening for this page[1]. Any evidence of memory leaks or such?

One interesting option might be to call XSynchronize(qt_xdisplay(), true) from gdb and try to ctrl-c a bit to see where konq is... Though if it's unreproducible, it may be unfixable from this report :(

[1] Most commonly, slow page drawing happens when the page has some sort of transparent background, and we don't succeed in preblending it for some reason --- and drawing transparent pixmaps in X is often painfully slow.
The background code in KHTML has continuously evolved to try to handle more and more cases...

Comment 3 Allan Sandfeld 2007-09-10 10:47:19 UTC

Slow repaints are often caused by "fixed" backgrounds, this is because we start repainting the entire screen on every update to support them. 

They repaint much faster in KDE4 though, because Qt4 is so damn fast.

Comment 4 Gregor B. Rosenauer 2007-09-13 23:13:45 UTC

To give a concrete example of what I think is the same bug:
http://blogs.sun.com/tientien/

Xorg goes up to >70% when loading and later when scrolling through the page.
Maybe related to bug 134776 and bug 133529.

I am using the opensource nv-driver, but I afaik this has at least 2d-acceleration.

Comment 5 Sami Liedes 2007-09-13 23:30:54 UTC

For me (with free ATI drivers) using XAA instead of EXA in xorg.conf seems to have resolved this issue.

Comment 6 km 2010-06-25 14:10:26 UTC

I have the same problem and it doesn't seem to have anything to do with the pages itself (bacground etc.). Sometimes scrolling the pages in all the tabs in one window of Konqueror becomes very slow, while the same pages opened in different windows are fast.

Comment 7 Dawit Alemayehu 2012-01-04 19:08:05 UTC

I doubt this is valid today, but I will leave it to the khtml folks to deal with it.

Comment 8 Janek Bevendorff 2012-06-18 18:11:52 UTC

Message from the Bugsquad and Konqueror teams: This bug is closed as outdated, as we do not have the manpower to maintain the KDE3 version anymore. If you still can reproduce this issue with Konqueror 4.8.4 or later, please open a new report. Thank you for your understanding.