Open Bug 265437 Opened 20 years ago Updated 2 years ago

Debug/Verification/Transparence make X server eat all cpu

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: mmokrejs, Unassigned)

Details

Attachments

(4 files)

jprof output
67.07 KB, application/octet-stream
Details
no freetype and no xtt
50.27 KB, application/octet-stream
Details
jprof - almost no extra modules loaded in X
35.52 KB, application/octet-stream
Details
font.antialias.min set to 1000
33.12 KB, application/x-bzip2
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.54  [en]
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20041021

resource:///res/samples/test13.html

top - 15:18:53 up  4:19,  5 users,  load average: 1.83, 1.39, 1.18
Tasks: 173 total,   2 running, 171 sleeping,   0 stopped,   0 zombie
Cpu(s): 47.3% us,  9.2% sy,  0.0% ni, 43.5% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   1032616k total,  1028152k used,     4464k free,    40808k buffers
Swap:  8032492k total,        0k used,  8032492k free,   376576k cached
PID to kill: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 8746 root      16   0  169m  29m 143m R 80.0  3.0   4:48.99 X                  
19781 mmokrejs  15   0 79444  51m  51m S 28.9  5.1   1:22.18 mozilla-bin   

Closing this page with test releases all the cpu back so 99.1% is idle.

 


Reproducible: Always
Steps to Reproduce:
1.
2.
3.
If you'd like to say it's a bug in Xfree, I have no DRI and:
XFree86 Version 4.4.99.13
Release Date: 12 September 2004

-> views (?)
Assignee: general → roc
Component: Browser-General → Layout: View Rendering
QA Contact: general → ian
(In reply to comment #0)
> resource:///res/samples/test13.html
> 
> Closing this page with test releases all the cpu back so 99.1% is idle.

I can confirm this for an homemade linux aviary build of today (10-22).

Ofcourse the page is in an endless loop and that might eat cpu.

Steps to reproduce:
1. Open resource:///res/samples/test13.html
2. View cpu usage, or notice the slow response time of the system
Martin, are you running an optimized build or a debug build?
I have used ./configure  --disable-optimize --enable-debug
--with-gssapi=/usr/heimdal --enable-crypto

The --with-gssapi causes heimdal (kerberos5 implmementation) to be detected, but
during runtime the library is not found. It should have been linked in properly,
or -Rpath should be set. However, I was told by "timeless" not to care about
this. ;) It's filed as a separate bugreport.
Right.  Could you please retest with a --disable-debug --enable-optimize build?
 Testing performance in a debug build is utterly pointless.  Debug builds do a
lot more work than optimized ones.
Disabling debug and enabling optimization does help a bit, so the system is at
least more responsive. However, it still eats CPU:

top - 21:24:29 up 10:57,  5 users,  load average: 0.35, 0.16, 0.09
Tasks: 165 total,   2 running, 163 sleeping,   0 stopped,   0 zombie
Cpu(s): 45.7% us, 10.7% sy,  0.0% ni, 43.3% id,  0.0% wa,  0.2% hi,  0.2% si
Mem:   1032616k total,  1017968k used,    14648k free,    51096k buffers
Swap:  8032492k total,        0k used,  8032492k free,   345276k cached
PID to kill: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
 8744 root      16   0  156m  16m 142m R 88.0  1.6   1:09.37 X                  
17400 mmokrejs  15   0 38024  21m  20m S 23.4  2.2   0:06.48 mozilla-bin   

The system is a singleprocessor, overclocked Pentium IV at 3.44GHz with
hyperthreading enabled, hence 2 cpu's. ;)
For comparison, on my system (XFree86 4.3, p3-733 CPU, no DRI), Mozilla + X use
about 50% of the CPU on that testcase. X is completely responsive.  I would
suggest building a jprof enabled build, running with sync X calls, and profiling
to see which X calls are actually taking so much time...
Attached file jprof output — 
JPROF_FLAGS="JP_DEFER JP_PERIOD=0.005" /usr/local/bin/mozilla --sync

enabled profiling while having blankpage in the only one browser window with
"kill -PROF"
stopped browsing with SIGUSR1 before closing the test

I have noticed that scrollbars in mozilla appear and disappear as the moving
text shuffles around. They constantly reposition the window in browser and
maybe even this is the cause, or would at least help I believe.
The profile shows that of the 2892 total hits, 1492 are under
nsXFontAAScaledBitmap::DrawText8.  Of these, fully 1023 are under XGetSubImage.

Martin, it looks like you're using client-side anti-aliasing (with freetype). 
Does disabling that affect things any?
Attached file no freetype and no xtt — 
Disabling Load "freetype" line did not help, as Load "xtt" line included
freetype.
I don't much difference, load is 0.8 and X takes most CPU on both HyperThreaded
processors.
I took almost everything out of XF86-Config, except DDC and int10. So, I've
removed:

Section "Module"
	#Load  "record"
	#Load  "extmod"
	#Load  "GLcore"
	Load  "ddc"
	#Load  "dbe"
	#Load  "drm"
	#Load  "dri"
	#Load  "glx"
	#Load  "xtrap"
	#Load  "type1"
	#Load  "speedo"
	#Load  "freetype"
	#Load  "bitmap"
	#Load  "vbe"
	Load  "int10"
	#Load  "xtt"
EndSection

Anyway, no dramatic improvement, if at all.
BTW: I run at

        DefaultDepth 16
I meant disabling the client-side antialiasing in Mozilla (via the appropriate
preferences).  I don't think we use the server freetype module.
I don't remember/see any such option under Preferences. Just tell me where to
find it, sorry.
I don't believe there's ui for it....  What's the value of the
"font.FreeType2.enable" pref in about:config?  Make sure it's set, and to false.
font.FreeType2.autohinted is false
font.FreeType2.enable is false
font.FreeType2.printing is true
font.FreeType2.unhinted is true
Hmm... I wonder why we end up in nsXFontAAScaledBitmap then...

Could you set the "font.antialias.min" preference to 1000 or something
(something bigger than the font size in that testcase) and retest?
verified in about:config

CPU still used about 80%
BTW: The original value was 10
Attachment #163732 - Attachment mime type: application/octet-stream → application/x-bzip2
50% of the time is still in sending backgrounds to/from the X server while doing
antialias alpha blending...
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Still happens with

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051122 SeaMonkey/1.5a

./configure --disable-optimize --enable-debug='-g3 -O0' --enable-debug-modules=all --enable-debugger-info-modules --enable-detect-webshell-leaks --enable-svg --enable-svg-renderer-libart --enable-image-decoders=all --with-qtdir=/usr/qt/3 --enable-application=suite --disable-freetype2 --enable-default-toolkit=gtk2 --enable-xft


Is this still happening ?
Still happens with 

about:buildconfig

Source

Built from http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0274a35f0e16
Build platform
target
i686-pc-linux-gnu

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align -W -Wno-long-long -pedantic -fno-strict-aliasing -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_mmokrejs -DTRACING -ggdb
c++ 	gcc version 4.3.3 (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 	-fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -fno-strict-aliasing -fshort-wchar -pthread -pipe -DDEBUG -D_DEBUG -DDEBUG_mmokrejs -DTRACING -ggdb

Configure arguments
--disable-optimize --enable-debug=-ggdb --enable-debug-modules=all --enable-debugger-info-modules --enable-detect-webshell-leaks --enable-svg --enable-svg-renderer-libart --enable-image-decoders=all --with-qtdir=/usr/qt/3 --enable-application=suite --disable-freetype2 --enable-jprof --enable-default-toolkit=cairo-gtk2 --enable-xft --disable-gssapi --disable-optimize --enable-debug=-ggdb --enable-debug-modules=all --enable-debugger-info-modules --enable-detect-webshell-leaks --enable-svg --enable-svg-renderer-libart --enable-image-decoders=all --with-qtdir=/usr/qt/3 --enable-application=suite --disable-freetype2 --enable-jprof --enable-default-toolkit=cairo-gtk2 --enable-xft --disable-gssapi --enable-application=../suite --disable-official-branding --with-branding=../suite/branding/nightly --cache-file=.././config.cache --srcdir=/home/mmokrejs/proj/comm-central/src/mozilla 

while accessing http://www.mozilla.org/newlayout/samples/test13.html
QA Contact: ian → layout.view-rendering
Component: Layout: View Rendering → Layout: Web Painting
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: