Version: (using KDE Devel) Installed from: Compiled sources Compiler: gcc3.2.1 OS: Linux The webpage http://www.dnevnik.bg (once loaded entirely) flashes its contents in konqueror while having javascript enabled, and also lags the computer (as opposed to when it is disabled). I could not reproduce this "effect" in neither opera nor mozilla, but has been around for quite some time in konqueror and is still in cvs (last compiled both kdelibs and kdebase on 01/15/2003).
Doesn't flash anymore in HEAD, but takes a lot of RAM and the horizontal scroll bar increases in length.
Subject: Re: http://www.dnevnik.bg blinks and consumes a lot of processor resources when javascript is enabled I do not see any blinking using KDE CVS Packages 20031020 for Debian. The page (at the date of this report) takes a lot of CPU to be displayed, probably due to their scroller JS stuff.
The bottom scroll bar continues to expand. It is hard to navigate up and down the page due to resource exhaustion. The top scroller works flawlessly in Mozilla. I actually thought Konq had more IE compatibility than Moz. But it seems the site has DOM errors as reported by the bug button.
I see similar problem on http://nt.interia.pl/ - there is javascript scroll and whole konqueror blinks. [arekm@mobarm arekm]$ konqueror --version Qt: 3.2.1 KDE: 3.1.92 (CVS >= 20031019) Konqueror: 3.1.92
*** Bug 44690 has been marked as a duplicate of this bug. ***
I also see that http://nt.interia.pl/ flashes/blinks a lot.... (KDE 3.1.93)
*** Bug 69483 has been marked as a duplicate of this bug. ***
*** Bug 70415 has been marked as a duplicate of this bug. ***
*** Bug 74978 has been marked as a duplicate of this bug. ***
*** Bug 68593 has been marked as a duplicate of this bug. ***
*** Bug 74510 has been marked as a duplicate of this bug. ***
It would be great if we can "renice" the Javascript in relation to UI response so that UI priority is always higher than Javascripts.
*** Bug 77210 has been marked as a duplicate of this bug. ***
NOT solved with 3.2.1!!! SuSE 9.0. "renice" isn't the "right" answer, I think. -Dieter
This is improving. The scroller is now working on www.dnevnik.bg ( CVS ). Problems remaining: it is not exactly in the right position, the bottom scrollbar still resizes occasionally, sometimes memory consumption increases into an unusable state, but for the most part it is better than it used to be. > > From: Dieter "N > Date: 2004/03/10 Wed PM 02:29:20 PST > To: mtanev@adelphia.net > Subject: [Bug 53114] http://www.dnevnik.bg blinks and consumes a lot of processor resources when javascript is enabled > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=53114 > > > > > ------- Additional Comments From dieter.nuetzel hamburg de 2004-03-10 23:29 ------- > NOT solved with 3.2.1!!! > > SuSE 9.0. > > "renice" isn't the "right" answer, I think. > > -Dieter >
*** Bug 75374 has been marked as a duplicate of this bug. ***
*** Bug 80775 has been marked as a duplicate of this bug. ***
Yes, it stays with SuSE 9.0, Kernel 2.6.5-10.6. KDE 3.2.2, Qt 3.3.2 www.ft.com shows it, too. -Dieter
unfortunatelly guys, this is still the case. Sites with scroll in js are using helarious number of resources,both cpu and ram
The problem still persists (http://www.dnevnik.bg/ and fakty.interia.pl). Qt: 3.3.2 KDE: 3.2.2 Konqueror: 3.2.2
Problem still exists with QT 3.3.2 and KDE 3.2.2 on www.soelden.com and www.telering.at
same problem with www.muenchen.de (official site munich)
Unfortunatelly the problem still exists in KDE 3.3_alpha1, Qt 3.3.2
Another page still showing the problem with recent cvs is www.noen.at Does nobody of the khtml developers have an idea how to solve that?
Still exists (KDE-3.2.3/Gentoo-2004.2/URL: www.chip.de) Greetings Elias P.
*** Bug 84474 has been marked as a duplicate of this bug. ***
The bug is still present in Konqueror 3.2.91 (using KDE 3.2.91 (3.3 beta1)).
*** Bug 62511 has been marked as a duplicate of this bug. ***
*** Bug 55445 has been marked as a duplicate of this bug. ***
*** Bug 60114 has been marked as a duplicate of this bug. ***
I think if the news are scrolled the whole window is redisplayed as you can reduce the CPU time by decreasing the window size. André
>I think if the news are scrolled the whole window is redisplayed as you can reduce the CPU time by decreasing the window size. > > this was suggested by me earlier while discussing matter with developers on IRC. I guess window gets redisplayed because size is changing. you can see quite often on these scrolls that vertical scrollbar is changing it's size.
But this happens also when the size doesn't change, i.e. the news ticker on http://www.chip.de
A configuration to lower the priority of Javascripts (i.e. renice) would be a good solution if it is easy to implement, it returns most of the needed UI responsiveness without writing too much code...
Unfortunately the problem still exists in KDE 3.3_rc2
No more horizontal scrollbar in 3.3.1. Hurray!
*** Bug 91498 has been marked as a duplicate of this bug. ***
*** Bug 78485 has been marked as a duplicate of this bug. ***
This is a comment by Stephan Kulow about this problem, posted on kfm-devel: It's a quite ugly problem as more and more pages do that crap (as it works in all other browers just fine) - including one of my daily visited sites ;(. But the gtk-webcore shares the behaviour, so I assume safari does too. There is indeed no relayouting, but too much painting going on. Greetings, Stephan
Based on my observations, Safari works OK with this. On Friday 12 November 2004 02:54, Dik Takken wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=53114 > > > > > ------- Additional Comments From d.h.j.takken phys uu nl 2004-11-12 11:54 > ------- This is a comment by Stephan Kulow about this problem, posted on > kfm-devel: > > It's a quite ugly problem as more and more pages do that crap (as it works > in all other browers just fine) - including one of my daily visited sites > ;(. > > But the gtk-webcore shares the behaviour, so I assume safari does too. > There is indeed no relayouting, but too much painting going on. > > Greetings, Stephan
CVS commit by ggarand: Pragmatic incremental repaints: be accurate on layered objects, conservative on objects in normal flow. Fixes performance issues on repeated relayouts. BUG: 53114 M +36 -0 ChangeLog 1.354 M +29 -21 khtmlview.cpp 1.675 M +2 -0 khtmlview.h 1.216 M +4 -0 rendering/bidi.cpp 1.204 M +13 -2 rendering/render_block.cpp 1.57 M +0 -4 rendering/render_box.cpp 1.249 M +31 -0 rendering/render_canvas.cpp 1.155 M +6 -0 rendering/render_canvas.h 1.57 M +59 -11 rendering/render_layer.cpp 1.47 M +5 -0 rendering/render_layer.h 1.23 M +43 -7 rendering/render_object.cpp 1.276 M +6 -0 rendering/render_object.h 1.201 M +5 -0 rendering/render_table.cpp 1.268
On Monday 13 December 2004 03:11, Germain Garand wrote: > Pragmatic incremental repaints: be accurate on layered objects, > conservative on objects in normal flow. > Fixes performance issues on repeated relayouts. You rock, and for my case (www.chip.de) KHTML even seems to be faster than Fire Fox :-)
Hi! Sorry, not perfect jet while http://www.stipendium.at/stbh/ works nicely, on the next page with the same layout http://www.stipendium.at/stbh/download.html the running text still uses maximum CPU (CPU usage goes back to normal when hoovering over the running text, which stops the running text) cu ferdinand
Are you guys running 3.4 ALPHA (CVS)? Thanks, Dieter
On Tuesday 14 December 2004 14:46, Dieter Nützel wrote: > Are you guys running 3.4 ALPHA (CVS)? CVS :-)
mmh, don't quite know what it is about, but I've just seen this and thought I'd comment the link http://www.deviantart.com here; the username/password boxes and the login button dance around like it's 1999..
I don't see any moving text on www.stipendendium.at/stbh. The username/password on deviantart.com is probably the same as the jitterbug reported by aseigo.
I don't see konqueror or X in top when openening the URLs in #43 - please open a new bug report for it if you do. The same for dancing widgets - but as Allan said there is already one.
*** Bug 101235 has been marked as a duplicate of this bug. ***
Hi, the current version (KDE 3.5 SVN) still needs much resources. On my AMD XP 2800 Konqueror and Xorg needs 40% CPU time (27 and 13%) on www.chip.de even if the scrolling area isn't visible. In this case Firefox causes no X load. Cheers, André
Just FYI, now it's about 1% CPU usage, great work :-) Not sure if this is related to Xorg, NVIDIA drivers or recent changes in khtml. I'm just happy that it works so well :-)
Which site have you tested? The 'original' http://www.dnevnik.bg/ have no scrolling text. (I can't see it ;-) ) -Dieter PS But YES, the rendering speed is great, now (3.5.4).