Bug 117834 - konqueror html w/ javascript has high (80%) cpu usage
Summary: konqueror html w/ javascript has high (80%) cpu usage
Status: RESOLVED FIXED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-07 03:14 UTC by Michael Simmons
Modified: 2006-01-22 03:08 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
the javascript in its entirity (3.03 KB, text/plain)
2005-12-07 03:19 UTC, Michael Simmons
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Simmons 2005-12-07 03:14:44 UTC
Version:            (using KDE KDE 3.4.3)
Installed from:    Gentoo Packages
Compiler:          gcc version 3.4.4 
OS:                Linux

The web page
http://www.scied.science.doe.gov/scied/fast/about.html
uses a javascript animation of some sort that uses 80% of the cpu on an AMD64 2GHz. Mozilla 1.7.12 with javascript enabled was not affected at all.

The offending javascript follows:
=================================
/* chaser.js
 * by Aaron Boodman v1.0 000919
 * Copyright (c) 2000 Aaron Boodman. All Rights Reserved.
[snip...get the full license agreement from the linked page]
*/
/*[snip comments]*/
var oChaser = {
  topMargin : 250,
  callRate : 10,
  slideTime : 1200,
  maxDiff : document.all ? document.body.clientHeight : window.innerHeight,
  isIE : document.all ? true : false,
  chaserDiv : document[document.all ? "all" : "layers"]["myChaser"]
}

/*snip comments*/
window.setInterval("oChaser.main( )", oChaser.callRate)

/*snip comments*/
oChaser.main = function( )
{
  this.currentY	= this.isIE ? this.chaserDiv.style.pixelTop : this.chaserDiv.top
  this.scrollTop = this.isIE ? document.body.scrollTop : window.pageYOffset
  var newTargetY = this.scrollTop + this.topMargin

  if ( this.currentY != newTargetY ) {
    if ( newTargetY != this.targetY ) {
      this.targetY = newTargetY
      this.slideInit( )
    }
    this.slide( )
  }
}

/*snip comments*/
oChaser.slideInit = function( )
{
  var now = new Date( )
  this.A = this.targetY - this.currentY
  this.B = Math.PI / ( 2 * this.slideTime )
  this.C = now.getTime( )

  if (Math.abs(this.A) > this.maxDiff) {
    this.D = this.A > 0 ? this.targetY - this.maxDiff : this.targetY + this.maxDiff
    this.A = this.A > 0 ? this.maxDiff : -this.maxDiff
  } else {
    this.D = this.currentY
  }
}

/*snip comments*/
oChaser.slide = function( )
{
  var now = new Date( )
  var newY = this.A * Math.sin( this.B * ( now.getTime( ) - this.C ) ) + this.D
  newY = Math.round( newY )

  if (( this.A > 0 && newY > this.currentY ) ||
    ( this.A < 0 && newY < this.currentY )) {
		
      if ( this.isIE )this.chaserDiv.style.pixelTop = newY
      else this.chaserDiv.top = newY
  }
}
Comment 1 Michael Simmons 2005-12-07 03:19:15 UTC
Created attachment 13795 [details]
the javascript in its entirity
Comment 2 Maksim Orlovich 2005-12-07 03:24:29 UTC
LOL. That JS has no chance whatsoever of working on mozilla. And the CPU usage in konqueror? it fills the error log. There was some other bug report about it, I think I'll put in a cap
Comment 3 Michael Simmons 2005-12-07 03:41:22 UTC
I don't know enough about javascript one way or the other, I'll go ahead and close this if it isn't of any help.
Comment 4 Maksim Orlovich 2005-12-07 03:45:23 UTC
No, this is very helpful, I am constantly bugging users in #kde that I don't have enough performance problems to fix :-). And the JavaScript on the page, and the reason for our slowness gave me a good laugh.

Thanks again for reporting this
Comment 5 Michael Simmons 2005-12-07 04:04:19 UTC
Ok, after re-reading the comments I understand what you meant by filling the error log.  I was wondering why there was all the cpu activity but the page was visually static.  I'll leave it to someone who know what they are doing to close the bug.  This is the first time I've reported a bug.
Comment 6 Maksim Orlovich 2006-01-22 03:07:59 UTC
SVN commit 501092 by orlovich:

Make this thing actually update incrementally and limit to 2K messages
Fixes #117834 (I think there was some other report, too, but I can't find it)
BUG:117834


 M  +5 -5      kjserrordlg.ui.h  


--- branches/KDE/3.5/kdelibs/khtml/kjserrordlg.ui.h #501091:501092
@@ -10,14 +10,14 @@
 
 void KJSErrorDlg::init()
 {
-    _errorText->setText("<qt>");
+    _errorText->setTextFormat(QTextEdit::LogText);
+    _errorText->setMaxLogLines(2048);//Limit to about 2K errors so we don't use much CPU
 }
 
 void KJSErrorDlg::addError( const QString & error )
 {
-    // Argh why doesn't QText* interpret html tags unless I use setText()?
-    // This is really inefficient!
-    _errorText->setText(_errorText->text() + "<br>\n" + error);
+    
+    _errorText->append(error);
 }
 
 void KJSErrorDlg::setURL( const QString & url )
@@ -28,5 +28,5 @@
 void KJSErrorDlg::clear()
 {
     _errorText->clear();
-    _errorText->insert("<qt>");
+    init();
 }