| Summary: | QTextEdit responds slowly to keypress | ||
|---|---|---|---|
| Product: | [Unmaintained] kdelibs | Reporter: | boris <borizz> |
| Component: | qt | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cfeck, colesen, giovanni, hkBst, info, jtscsousa, kyron, mmodem00, rolandwolters |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
input bug example very slow
modified input bug example - still slow modified input bug example - still slow the whole debug output Another gdb output, this time with a kopete window kontact gdb output while input field runs in slow motion xtrace-output of konqueror session going crazy I used Valgrind to watch Konqueror when the bug hit it. This is the ouput. |
||
EXTRA: I rebuild kdeartwork, and now the input slowness is much less in a yabb input form, but it hasn't changed in bugs.kde.org input forms. I believe any Qt widget on a HTML page is slow, as the dropdownboxes on the bug report page are slow too. I have this exact same problem (right down to X taking up a huge amount of CPU resources). I have KDE 3.4 and the Konqueror that comes with it running on Fedora Core 3. I don't know if this bug existed in Konqueror from KDE 3.2, but it's too late to check now. I have exactly the same problem on 4 different machines (three x86-systems and one x86_64 system). They all run SUSE Linux 9.2 with KDE 3.4. I did not experience this problem with KDE 3.3 or 3.2 so this seems to be a new bug. The problem occurs only on some websites where you want to enter something into a <textarea></textarea> from field. If you quickly type something into such an textarea form field, e.g. "test", the first letter appears immediately but for each following letter it takes 8 seconds to appear on the screen. So for "test" it takes about 30 seconds to appear on the screen. During this time the Konqueror Window hangs/is not reacting and the mouse pointer disappears behind the textarea field. I really would like to post some sample websites, but I don't know one that is common accessible. But I saved the HTML source code of one of those pages and post it as attachment as an example: inputbug_original.html <-- is the source code of the original page inputbug_fewcode.html <-- step by step, I removed as many dispensable code in inputbug_original.html to get a slim code example... it seems, that a javascript function is causing this, but I'm not quite sure if this is the only problem, because doing textinput in inputbug_fewcode.html is not as slow as in inputbug.original.html I tested these examples with firefox... there's no delay. Created attachment 10724 [details] input bug example very slow see comment #3 by Jörg Hermsdorf Created attachment 10725 [details] modified input bug example - still slow see comment #3 by Jörg Hermsdorf Created attachment 10726 [details] modified input bug example - still slow see comment #3 by Jörg Hermsdorf Comment on attachment 10726 [details]
modified input bug example - still slow
was sent twice
Hi. I'm the opener of this bug. Let me add that I still have this problem, using KDE 3.4.0 (on gentoo, with xorg 6.8.2 and fglrx ati-drivers, gcc version 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110-r2, ssp-3.4.3.20050110-0, pie-8.7.7) ) It's been happening a bit less as of late though. In the beginning it was really slow, but it's been speeding up too. Boris. PS: To show that I'm not some kind of dumb gentoo ricer (I know most upstream devs hate gentoo users), here are my cflags: CFLAGS="-march=athlon-xp -O2 -fomit-frame-pointer -pipe". Seems similar to #100234. There are two different bugs: - one bug is the kjs bug which has been solved with kde 3.4.1 - one bug seems to depend on ATI-fglrx-drivers Can someone confirm, that with loaded fglrx-drivers the input fields slow down, and without not? Hello, I have this bug on two machines with different graphic chip : one with NVIDIA and another with ATI radeon mobility (radeon driver). This bug is new from KDE 3.4.0 (and is still present in 3.4.1) ; everything were fine before. Does it make sense to open a new bug with a new name like "konqueror does not like 3rd party graphic drivers" or something like that to make it clear? I think I got it at least for ati and need confirmation: When I change the option-value Option "VideoOverlay" "on" to "off" and switch Option "OpenGLOverlay" "off" to "on" then everything works (by know - not much tested, but it looks good). Can someone confirm this? Is there a similar option for nvidia? And: Please vote for this bug, we need someone who can have a more detailed look at the reasons. Nope. I've just tested with the two option VideoOverlay & OpenGLOverlay to off and on. The bug is still there. X take no CPU but Konqueror freeze for 2 ~ 5 secondes each time a use the mouse to click on text. I notice that if I only use keyboard there's no problem at all. Strange. I use the radeon driver and I have an ATI Radeon Mobility M6LY Solved it for me. I can live with non-accelerated video for a while. Weird though. *** This bug has been confirmed by popular vote. *** Boris: what solved your problem? Changing the video driver to native xorg, or changing the options? Sorry, I should have mentioned. Changing the options solved it. I am still running the ATI binary fglrx drivers. By the way, it's still working fine, even after several reboots. @Jörg Hermsdorf: It seems that your bug is realted to #100234 - that should be solved in KDE 3.4.1. Can you confirm this? And, is there no developer who could say a word about the workaround with the video-drivers? Another interesting thing: I can workaround this problem when I deactivate klippers option to store content when exiting. If you can confirm this behaviour, we should mark this bug as a double of Bug #91357 . yes, this is linked to klipper ! Exiting klipper solve this problem. Thanks for the workaround. Hm, can someone mark this as a duplicate? Sorry guys, but not for me. Turning that klipper option off or exiting klipper didn't help. For me its the Xv extension (with fglrx) that does it. So again, it is a bug describing to different problems? One about a klipper problem, one about a video overlay problem? The most weired thing is, that both workarounds work for me! But my feling is that everything works a little bit faster with the fglrx fix, but that is maybe just a feeling. A solution maybe? Having the same problem, some textboxes are slow and some are not. One thing that I have noticed is that if you make some new lines (enter that is) and tries to write on every line, you will at some point see that your cpu-usage drops. Example, I have a totally empty textarea that is 20 rows in height, and it's not until I hit row ~18 everything starts to run smoothly. On sure way to make the syrup go away is to make enough new lines so that you get a scrollbar and the first line diseappears. Using KDE 3.4.1 from alioth.debian.org, Xfree86 4.3.0.dfsg.1-14, AMD 2500+, Matrox G550. It's not really a solution, but that does work. Maybe the devs can do something with this information. As long as the field is larger than the box (there is text or returns out of view) the box is fast. Remove the enters, and it gets slow again. *** Bug 95620 has been marked as a duplicate of this bug. *** I would like to confirm this bug. I am running gentoo on a dual Opteron with concervative CFLAGS (CFLAGS="-march=opteron -O2 -pipe"). Video driver is the ati driver included in Xorg 6.8.2 (and xconf is automatically generated by xorg). KDE version is 3.4.1. Klipper is not activated on this system. I can easyly recreate the slowness by editing any MediaWiki page (for example). *** Bug 124430 has been marked as a duplicate of this bug. *** *** Bug 132614 has been marked as a duplicate of this bug. *** Would it help to provide a debug output? I can easily install a --debug enabled version on my system (vut you have to tell me the steps I have to do to run gdb). I have seen this with a number of different display adapters. Does anyone have a surefire way to reproduce it? Roland: If you could install debuggable binaries and when the bug kicks in, attach gdb to the process and get a backtrace, like so: gdb <program> <PID> bt The problem is not reproducable every time in every case - but usually it is enough to edit one or two big wikipedia articles to get it immediately. To get it in kmail or kedit I have to work quite a lot of time in these programs. What I did now to create the attached gdb session: I first installed the -debuginfo packages necessary for this process, and then run konqueror to edit the article "History of Linux" in the german wikipedia: http://de.wikipedia.org/wiki/Geschichte_von_Linux I edited the article until I the slow down appeared, and then entered quite a lot of garbage (just hammering on the keyboard). While konqueror tried to display all entered characters in slow motion I started gdb, and produced the attached output. After I detached gdb konqueror was still working on displaying all characters I previously entered. Some more things about this bug, from my point of view: - it can happen in almost all KDE apps - please change the subject of this bug therefore! (spotted in kmail, kopete, kate, konqueror) - "slow down" means under 5 chars per second (that's what I've counted) - the slow down does not happen for copy&paste - even if I stop entering chars konqueror is still very unresponsive; if I move other app windows over konqueror, large artefacts are produced Created attachment 17421 [details]
the whole debug output
Because the graphic adapter was mentioned: I use the proprietary fglrx drivers
for my ATI Radeon card.
And about the debug symbols: you see there a lot of CRC missmatches, if that is
a bug of the debuginfo-packages I use, please tell me so I can fill a bug
report against that at the Fedora bugzilla
Created attachment 17423 [details]
Another gdb output, this time with a kopete window
I made this gdb when a kopete input chat window hat suddenly the same problem.
Again I started to hammer on my keyboard and tried to attach gdb while the
input field filled up slowly with the entered characters.
But: this time, in oposite to the other gdb output, when I attached gdb
suddenly all charakters appeared in no time - and then gdb started working. So
there were no characters still to be displayed when gdb run through.
And, remeber: please change the subject of this bug report - this is not khtml
specific (at least not for me).
Created attachment 17503 [details]
kontact gdb output while input field runs in slow motion
What this time happened: I accessed the kmail module inside kontact and
answered an e-mail. While editing the answer suddenly the input filed slowed
down.
Then I entered quite a lot of garbage (just hammering on the keyboard). While
the mail windows tried to display all entered characters in slow motion I
started gdb, hooked on the kontact pid and produced the attached output.
After I detached gdb the e-mail windows continued with displaying the rest
characters of these I previously entered.
Created attachment 17785 [details] xtrace-output of konqueror session going crazy This bug is driving me nuts, so I tried to find some other way to gather more information what's happening here. In bug #133529 there was the tool xtrace mentioned (http://xtrace.alioth.debian.org/): "Xtrace fakes an X server and forwards all connections to a real X server, displaying the communication between the clients and the server in an (well, thoretically) human readable form. " I run it, and started konqueror in this way. I opened a wiki page, (http://de.wikipedia.org/wiki/Geschichte_von_Linux) and entered some garbage with the keyboard. After some characters the system already slowed down, so I killed konqueror (Strg+Alt+Esc) and saved the output of xtrace. However, the output is 11 MB uncompressed, so I'm not sure if it can be helpful at all - if I can help to make it smaller, just post a note. Why don't you run gdb before the input field slows down? I'm no experienced debugger, but when I used gdb some time ago my workflow was like this. 1. run gdb 2. start the program to be debugged from within the gdb-console In comment #31 Andreas Kling told me to attach the gdb when the bug kicks in, so I did exactly as he told me. I can go the other way as well if it helps or gives additional information. Here's my backtrace: #0 0x00002ac380ce9722 in __select_nocancel () from /lib/libc.so.6 #1 0x00002ac37e90bd7d in qt_xclb_wait_for_event () from /usr/qt/3/lib64/libqt-mt.so.3 #2 0x00002ac37e90d30c in QClipboardWatcher::getDataInFormat () from /usr/qt/3/lib64/libqt-mt.so.3 #3 0x00002ac37e90d93f in QClipboardWatcher::format () from /usr/qt/3/lib64/libqt-mt.so.3 #4 0x00002ac37e9acf1d in QMimeSource::provides () from /usr/qt/3/lib64/libqt-mt.so.3 #5 0x00002ac381e64438 in KHTMLPartBrowserExtension::updateEditActions () from /usr/kde/3.5/lib64/libkhtml.so.4 #6 0x00002ac381e8b4cf in KHTMLPartBrowserExtension::qt_invoke () from /usr/kde/3.5/lib64/libkhtml.so.4 #7 0x00002ac37e9b639c in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3 #8 0x00002ac37e9b7043 in QObject::activate_signal () from /usr/qt/3/lib64/libqt-mt.so.3 #9 0x00002ac37eafa909 in QTextEdit::contentsMouseReleaseEvent () from /usr/qt/3/lib64/libqt-mt.so.3 #10 0x00002ac37eab169e in QScrollView::viewportMouseReleaseEvent () from /usr/qt/3/lib64/libqt-mt.so.3 #11 0x00002ac381f6ad30 in khtml::RenderWidget::handleEvent () from /usr/kde/3.5/lib64/libkhtml.so.4 #12 0x00002ac381eea835 in DOM::HTMLGenericFormElementImpl::defaultEventHandler () from /usr/kde/3.5/lib64/libkhtml.so.4 #13 0x00002ac381ec8132 in DOM::NodeImpl::dispatchGenericEvent () from /usr/kde/3.5/lib64/libkhtml.so.4 #14 0x00002ac381ec6fb1 in DOM::NodeImpl::dispatchEvent () from /usr/kde/3.5/lib64/libkhtml.so.4 #15 0x00002ac381e6f13b in KHTMLView::dispatchMouseEvent () from /usr/kde/3.5/lib64/libkhtml.so.4 #16 0x00002ac381e6f8e8 in KHTMLView::viewportMouseReleaseEvent () from /usr/kde/3.5/lib64/libkhtml.so.4 #17 0x00002ac381e69c8d in KHTMLView::eventFilter () from /usr/kde/3.5/lib64/libkhtml.so.4 #18 0x00002ac37e9b5db2 in QObject::activate_filters () from /usr/qt/3/lib64/libqt-mt.so.3 #19 0x00002ac37e9b5e07 in QObject::event () from /usr/qt/3/lib64/libqt-mt.so.3 #20 0x00002ac37e9e8a68 in QWidget::event () from /usr/qt/3/lib64/libqt-mt.so.3 #21 0x00002ac37e9602a5 in QApplication::internalNotify () from /usr/qt/3/lib64/libqt-mt.so.3 #22 0x00002ac37e961091 in QApplication::notify () from /usr/qt/3/lib64/libqt-mt.so.3 #23 0x00002ac37dcbe5cf in KApplication::notify () from /usr/kde/3.5/lib64/libkdecore.so.4 #24 0x00002ac37e909ba4 in QETWidget::translateMouseEvent () from /usr/qt/3/lib64/libqt-mt.so.3 #25 0x00002ac37e908cc1 in QApplication::x11ProcessEvent () from /usr/qt/3/lib64/libqt-mt.so.3 #26 0x00002ac37e91795f in QEventLoop::processEvents () from /usr/qt/3/lib64/libqt-mt.so.3 #27 0x00002ac37e974a82 in QEventLoop::enterLoop () from /usr/qt/3/lib64/libqt-mt.so.3 #28 0x00002ac37e974932 in QEventLoop::exec () from /usr/qt/3/lib64/libqt-mt.so.3 #29 0x00002ac3811c4a0e in kdemain () from /usr/kde/3.5/lib64/libkdeinit_konqueror.so #30 0x0000000000407c86 in launch () #31 0x00000000004085d2 in handle_launcher_request () #32 0x00000000004089d2 in handle_requests () #33 0x0000000000409266 in main () #34 0x00002ac380c50134 in __libc_start_main () from /lib/libc.so.6 #35 0x0000000000404d09 in _start () *** Bug 138255 has been marked as a duplicate of this bug. *** *** Bug 141764 has been marked as a duplicate of this bug. *** Note: From the bt's, it doesn't look like KTextEdit is to blame.
Also, this pattern occurs in both attachment 17421 [details] and 17503:
QWidget::setMicroFocusHint ()
QTextEdit::updateMicroFocusHint ()
QTextEdit::insert ()
QTextEdit::insert ()
QTextEdit::keyPressEvent ()
Assign to qt component Created attachment 22085 [details]
I used Valgrind to watch Konqueror when the bug hit it. This is the ouput.
I could not reproduce this bug anymore today and have not experienced it in my normal surfing. Assuming it was a KDE3/Qt3 bug, closing this is fixed. Please reopen if necessary. |
Version: (using KDE KDE 3.3.2) Installed from: Gentoo Packages Compiler: gcc version 3.4.3 20041125 (Gentoo Linux 3.4.3-r1, ssp-3.4.3-0, pie-8.7.7) Using NPTL, linux-headers-2.6 and a 2.6 kernel OS: Linux Input fields on some webpages are very slow. Dragging a window over them creates large artifacts, and typing a sentence makes the page render slowly and X uses 99% cpu. The problem has been noticed on one piece of hardware, with about 3 software setups. The machine is a 2500+ Athlon with 512MB of RAM. The first configuration that had this bug had this software: GCC-3.3 XFree86 with FGLRX (ATi) binary drivers Gentoo NPTL, 2.6.8.1 kernel (ck patchset) Upgrade from KDE 3.3.0 The second configuration was really a clean wipe of the system and a reinstall: GCC-3.4 X.Org-6.8.0 with radeon opensource drivers Gentoo NPTL, 2.6.9 kernel (ck patchset) The third: GCC-3.4 XFree86 with FGLRX (I first presumed that the slow rendering was due to the radeon drivers being sucky) Gentoo NPTL, 2.6.9 vanilla kernel Here I also applied the anchor-fix patch. The strange thing is, the input box for forums.gentoo.org is not slow at all. But the bugzilla box I'm typing this in is slow, like input boxes on YaBB forums. I have no clue as to where this is coming from. I had no problems with KDE-3.3.0. Here is the top output taken while I was typing a sentence in a forum-post box on a YaBB forum: boris@stargazer boris $ sleep 1 && top -b -n 1 top - 23:11:43 up 1:15, 3 users, load average: 0.22, 0.18, 0.19 Tasks: 60 total, 2 running, 58 sleeping, 0 stopped, 0 zombie Cpu(s): 10.5% us, 0.8% sy, 0.0% ni, 87.6% id, 0.9% wa, 0.1% hi, 0.0% si Mem: 515272k total, 379680k used, 135592k free, 30436k buffers Swap: 136512k total, 0k used, 136512k free, 187452k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 8034 root 17 0 62756 46m 16m R 97.5 9.3 4:27.20 X 8193 boris 15 0 40364 9540 14m S 2.0 1.9 0:22.93 artsd 1 root 16 0 1360 492 1208 S 0.0 0.1 0:00.35 init 2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 3 root 5 -10 0 0 0 S 0.0 0.0 0:00.11 events/0 4 root 12 -10 0 0 0 S 0.0 0.0 0:00.00 khelper 5 root 15 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid 29 root 5 -10 0 0 0 S 0.0 0.0 0:00.12 kblockd/0 30 root 15 0 0 0 0 S 0.0 0.0 0:00.01 khubd 40 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pdflush 41 root 15 0 0 0 0 S 0.0 0.0 0:00.00 pdflush 43 root 10 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0 42 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kswapd0 44 root 15 0 0 0 0 S 0.0 0.0 0:00.00 cifsoplockd 629 root 25 0 0 0 0 S 0.0 0.0 0:00.00 kseriod 645 root 6 -10 0 0 0 S 0.0 0.0 0:00.00 ata/0 679 root 15 0 0 0 0 S 0.0 0.0 0:00.10 kjournald 813 root 16 0 1744 976 1424 S 0.0 0.2 0:00.00 devfsd 7443 root 15 0 1612 684 1440 S 0.0 0.1 0:00.00 syslog-ng 7596 root 16 0 2448 1080 2208 S 0.0 0.2 0:00.00 lisa 7836 root 16 0 6504 2368 5620 S 0.0 0.5 0:00.00 smbd 7839 root 16 0 3416 1412 2584 S 0.0 0.3 0:00.00 nmbd 7892 root 18 0 6504 2348 5620 S 0.0 0.5 0:00.00 smbd 7893 root 18 0 3256 1472 2892 S 0.0 0.3 0:00.00 sshd 7936 root 16 0 1616 716 1452 S 0.0 0.1 0:00.00 cron 8000 root 16 0 1496 672 1316 S 0.0 0.1 0:00.00 agetty 8001 root 16 0 1496 672 1316 S 0.0 0.1 0:00.00 agetty 8002 root 16 0 1496 672 1316 S 0.0 0.1 0:00.00 agetty 8003 root 16 0 1496 672 1316 S 0.0 0.1 0:00.00 agetty 8004 root 16 0 1496 672 1316 S 0.0 0.1 0:00.00 agetty 8005 root 16 0 1496 672 1316 S 0.0 0.1 0:00.00 agetty 8031 root 17 0 2496 728 2316 S 0.0 0.1 0:00.00 kdm 8035 root 16 0 3372 1668 2924 S 0.0 0.3 0:00.02 kdm 8143 boris 17 0 2248 992 1808 S 0.0 0.2 0:00.00 startkde 8173 boris 17 0 23032 10m 21m S 0.0 2.1 0:00.18 kdeinit 8176 boris 16 0 21768 9484 20m S 0.0 1.8 0:00.60 dcopserver 8178 boris 16 0 23516 10m 22m S 0.0 2.1 0:00.08 klauncher 8181 boris 15 0 27984 16m 25m S 0.0 3.2 0:00.90 kded 8195 boris 15 0 31516 16m 29m S 0.0 3.3 0:00.21 knotify 8196 boris 16 0 1348 316 1192 S 0.0 0.1 0:00.00 kwrapper 8198 boris 16 0 23668 12m 21m S 0.0 2.4 0:00.06 ksmserver 8199 boris 15 0 25476 14m 22m S 0.0 2.9 0:04.93 kwin 8203 boris 15 0 24052 12m 21m S 0.0 2.5 0:00.65 khotkeys 8204 boris 15 0 26436 16m 23m S 0.0 3.3 0:01.94 kdesktop 8206 boris 15 0 27308 17m 24m S 0.0 3.4 0:07.09 kicker 8207 boris 16 0 24256 11m 22m S 0.0 2.2 0:00.01 kio_file 8209 boris 15 0 25032 14m 22m S 0.0 2.8 0:00.22 klipper 8223 boris 15 0 44876 34m 31m S 0.0 6.8 1:38.62 konqueror 8226 boris 16 0 41912 28m 36m S 0.0 5.6 0:05.46 kmail 8227 boris 15 0 62284 25m 31m S 0.0 5.0 0:06.09 kopete 8578 boris 15 0 48872 11m 22m S 0.0 2.3 0:00.21 kio_http 8642 boris 15 0 45432 32m 29m S 0.0 6.4 0:05.36 juk 8645 boris 16 0 33444 20m 29m S 0.0 4.2 0:00.64 konqueror 8657 boris 15 0 48852 11m 22m S 0.0 2.3 0:00.12 kio_http 8661 boris 15 0 48920 11m 22m S 0.0 2.3 0:00.16 kio_http 8761 boris 15 0 28928 17m 25m S 0.0 3.5 0:03.42 kwrite 8780 boris 16 0 24140 11m 22m S 0.0 2.2 0:00.00 kio_http 8795 boris 15 0 26452 15m 23m S 0.0 3.0 0:00.55 konsole 8796 boris 16 0 2456 1284 2000 S 0.0 0.2 0:00.00 bash 8804 boris 15 0 1932 956 1720 R 0.0 0.2 0:00.00 top This input box im typing this in just speeded up. Very weird. After I pasted this top output, typing in this box only takes 1 to 3 % of my CPU, as it should be. Scrolling in it or dragging a window over it is still slow though. I already had the idea that it might be related to the Plastik style I'm using, so I switched to Lite v3 and tried again. Same thing.