244862 - scrolling sluggish on page with fixed background with GTK2+XFT build

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Boris Zbarsky [:bzbarsky]]

This is similar to bug 244506, but for XFT.  Profile data coming up.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Profiled a GTK2+XFT build, with tor's image patch from bug 244506.  As tor
points out, the ratios I list below may be somewhat off because X is async.

This is a little slower than a GTK1 no-xft build doing client-side bitmap
antialiasing, but not by a lot (10% or so).

About 20% of the time seems to be spent under XSync (called from 
_gdk_windowing_window_queue_antiexpose).

84% of the total time is spent waiting on X, looks like; about a (2:2:1 split
between _XFlush, _XSend, _XRead).

All the _XRead stuff is under that XSync call I mentioned.

_XFlush is under XRenderCompositeText8, _XFlushGCCache, XCopyArea, XDrawLine in
a 10:2:1:1 ratio.

_XSend is under XRenderCompositeText8, XRenderChangePicture, XRenderAddGlyphs in
a 10:1:1 ratio.

A total of 50% of the scrolling time is spent under XRenderCompositeText8, which
is called by XftGlyphFontSpecRender, which is called by
nsAutoDrawSpecBuffer::Flush, eventually.

About 5% of the time is spent under nsFontMetricsXft::EnumerateGlyphs, which
mostly spends its time in XRenderAddGlyphs (hence in _XSend).

The interesting thing is that while scrolling was slow and choppy the CPU meter
never went above 20% or so.  So all the lag is in the chatter with the X server,
not in actual CPU time....  Note that this is a local server.  I shudder to
think what this looks like on a remote connection.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: Zipped-up profile

Comment 3

[Christopher Blizzard (:blizzard)]

My guess is that there are two seperate things going on here:

1. The antiexpose code is important because it makes scrolling performance
_somewhat_ reasonable on Linux.  It's currently pretty well optimized, but
you're more than welcome to try to make it even faster.  (It uses XCopyArea if
there are no child windows, the guffaw scrolling method when there are child
windows.)

2. Sounds like flushing the drawing requests is causing a lot of pain because of
the text drawing is expensive.  I'm not sure there's much we can do about this,
either.  The text still needs to get drawn and pushed down the pipe.  Otherwise
scrolling would look hella-interesting.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Hmm.. So do we flush on each text draw request right now?  Since we're
double-buffering, could we try to flush once per view or once per widget or
something?

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Why not just put that flush in nsWindow, after the processing of a paint event?

Comment 6

[Christopher Blizzard (:blizzard)]

The flushing isn't associated with the drawing - it's associated with the
scrolling which are different.  The event processing looks something like:

1. Start scroll operation (window move and resize or XCopyArea depending on the
presence of child windows)
2. Manually expose newly exposed window (this is where the drawing takes place
including images, etc.)
3. Finish scroll operation (this generates the flush.)

Comment 7

[Mark Whitis]

Scrolling gives garbage in window when bottom of window is off screen and
browser is being slow for some reason.   Looks like a BITBLT error to me.   It
appears
that you (or the toolkit) do a BITBLT copy of the pixel data to its new location
but forgot to clear the bottom of the screen.   When the browser is non-responsive
this can easily result with the bottom  1cm  of text/graphics in the window
repeated 10 times or other less than artistic effects.  Why the browser becomes
sluggish is a separate issue.

Firfox 0.8/Linux 

Comment 8

[David E. Ross]

This might be a symptom of bug 124150.  See my comment 66 in that bug.  

Comment 9

[Boris Zbarsky [:bzbarsky]]

That's a bug filed on Windows.  The issues this bug is filed on are in Linux gfx
code...

Comment 10

[David E. Ross]

I have identified four different bugs that all seem to describe unsatisfactory
scrolling performance when a page has a background image with the style
position:fixed.  Besides this one and bug 124150, they are bug 201307 and bug
222198.  Is it not possible that all four reflect a single bug that affects
multiple platforms and operating systems?  

Comment 11

[Boris Zbarsky [:bzbarsky]]

It's possible, but it's not what the profiles seem to be showing... the
bottlenecks are in different places even for as simple a change as GTK2 vs GTK1.

Comment 12

[Jure Repinc (JLP)]

I just checked out the above mentioned page and scrolling is still slow with Firefox nightly 20060607 from trunk on my AMD Turion 64 notebook. Konqueror 3.5.3 is woorking fine. There are two additional pages that scroll slowly for me:
http://kongming.net/sgz/biographies/wu/huanggai.html
http://www.csszengarden.com/?cssfile=http://www.pro-ymd.co.jp/zen/sample.css

Comment 13

[David E. Ross]

Is this related to bug #124150?  

Have you tried scrolling the following:  

<http://www.rossde.com/test/fixed_bg_image_a.html>, which has a fixed background image with a transparent background

<http://www.rossde.com/test/fixed_bg_image_b.html>, which has a fixed background image with a non-transparent, white background

Until I got a faster PC, these scrolled very poorly under Windows.  The version with the non-transparent background seemed to scroll slightly better than the version with the transparent background.  

Since I saw bug #124150 with Windows, the underlying problem here might not be peculiar to Linux or UNIX.  

Comment 14

[Boris Zbarsky [:bzbarsky]]

There are some cross-platform issues, yes.  This bug is about the platform-specific issues on Linux.  There is not a single "underlying problem" in this case.

Then again, I already said that in comment 11 in response to your comment 10...

Comment 15

[Ryan Jones-Ward [:sciguyryan]]

Can anyone test this will a latest nightly build? If the bug can no longer be
reproduced it was likely fixed by bug 564991. Please mark it as such.

Comment 16

[Zack Weinberg (:zwol)]

WFM with 8.0 (probably not the same graphics card, though). I'm also gonna recategorize it under Core:Graphics in case it needs to be reopened.