On Tue, 2008-12-09 at 00:40 +0100, Zdenek Kabelac wrote: > 2008/12/9 Eric Anholt <[EMAIL PROTECTED]>: > > On Mon, 2008-12-08 at 12:32 +0100, Zdenek Kabelac wrote: > >> Hi > >> > >> Recently I've noticed that scrolling in firefox is getting very very > >> slow on some pages - especially those with some static background on > >> the sides of pages. So I've started oprofile - and to my surprise the > >> most of the time has been spent in two Xorg libexa functions: > >> > >> Of course I could be completely wrong in my interpretation of these > >> oprofile results - from the fast look into the exa/exa_offscreen.c > >> it seems like a major time is spent in some loop going through > >> possible quite large list of offScreenAreas? > >> > >> I'm running the latest fedora rawhide > >> xorg-x11-server-Xorg-1.5.3-5.fc10.x86_64 > >> X.Org X Server 1.5.3 > >> Release Date: 5 November 2008 > >> and linus-git kernel tree 2.6.28-rc7 > >> > >> Any ideas, solution ? > > > > My suspicion is that firefox is chewing through a lot more temporary > > pixmaps than it used to. I was just doing some profiling with UXA for > > scrolling in the slashdot comments section, and while things seem to be > > better than described by people using EXA, I'm still seeing unimpressive > > performance and indications that ff is using a lot of pixmaps (working > > set exceeding my 180MB of aperture space). We've got a few ideas to > > improve things for UXA performance still, so it may get better. It's > > already a win over EXA, since EXA's stuck with only 50MB of aperture > > space. > > > > On the other hand I've still got rendering issues with UXA, so you've > > been warned before you go playing with it. > > > >> > >> Zdenek > >> > >> > >> CPU: Core 2, speed 2200 MHz (estimated) > >> Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a > >> unit mask of 0x00 (Unhalted core cycles) count 100000 > >> samples % image name app name > >> symbol name > >> ------------------------------------------------------------------------------- > >> 35766 26.1526 libexa.so Xorg > >> exaOffscreenAlloc > >> 35766 100.000 libexa.so Xorg > >> exaOffscreenAlloc [self] > > > > This says to me that you're stuck allocating/freeing offscreen memory > > space to handle a working set that exceeds the size of your EXA > > offscreen space. UXA makes the pixmap offscreen space be unified with > > 3D and every other GPU activity. > > > So there is nothing which could improve the performace here - i.e. > better allocation logic instead of scanning possible very long list of > chunks to allocate/free pixmaps ? > > Should I open bugzilla for firefox - so they could play more nicely here?
Nope, on further examination ff is doing perfectly sensible cairo rendering and we're handling it poorly. We're moving from EXA to UXA, which fixes a lot of the performance problem by having an allocator that doesn't suck. The remainder of the fix would be accelerating trapezoids. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
