244506 - scrolling sluggish on page with fixed background under X11

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[fritz.heinrichmeyer]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.7) Gecko/20040521
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; de-AT; rv:1.7) Gecko/20040521

the mentioned page cannot be scrolled with

mozilla and firefox under freebsd (x11 i guess). This site can be browsed fine
with konqueror under x11 and with mozilla/firefox under windows.

Reproducible: Always
Steps to Reproduce:
1. reboot into freebsd
2. launch firefox or mozilla (0.8, 1.7rc2 respectively)
3. go to http://www.blogtari.com and scroll ...

Actual Results:  
xserver eats computing power

Expected Results:  
smooth  scroll like under windows or under x11/konqueror

Comment 1

[Olivier Cahagne]

CSS shows:
[...]
     background-attachment: fixed;
     background-image: url(../images/background_01c.gif);
[...]
I'm not a CSS expert but this looks similar to bug 90198, bug 201307 and bug 242364.

Comment 2

[Olivier Cahagne]

*** This bug has been marked as a duplicate of 90198 ***

Comment 3

[Boris Zbarsky [:bzbarsky]]

This has nothing to do with bug 201307 and bug 242364.

It's hard to tell what bug 90198 is all about, since all sorts of things have
been dupped to it, most likely covering multiple back-end problems.

So I'm going to reopen this, mark a dependency, and attach the profile results
in case someone familiar with painting gets a chance to take a look.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile results

Comment 5

[Boris Zbarsky [:bzbarsky]]

Short story (profiled a GTK1 non-xft build, as usual): 

We spend 95.4% of our time on this page in select().  select() is called from
_XSend and _XFlush (in about a 1:9 ratio).

_XSend is called almost exclusively by XFillPolygon, which comes from
nsCSSRendering::PaintBorder (by way of nsRenderingContextGTK::FillPolygon).

The callers of _XFlush are:

  XDrawString, _XFlushGCCache, _XEventsQueued, _XSetClipRectanges, XCreateGC.

XDrawString is called by text painting (and accounts for 2/3 of the time spent
scrolling on this page).

_XFlushGCCache is called by XSetClipMask, which is called by
gdk_gc_set_clip_rectangle and gdk_gc_set_clip_mask.  The former comes from
nsNativeThemeGTK::DrawWidgetBackground (for the scrollbar thumb); the latter
comes from nsImageGTK::DrawTile.

XCreateGC is also called pretty much only from nsImageGTK::DrawTile.

_XEventsQueued is called from XPending, which is called from g_main_iterate via
gdk_event_prepare.  Not sure what's up with this codepath and why it's taking
time in this case (about 5% of total).

_XSetClipRectanges is mostly called by XSetRegion, which comes from
nsGCCache::GetGC by way of gdk_gc_set_clip_region (the ultimate caller is
UpdateGC, called from nsFontMetricsGTK::DrawString and various other places).

So we're talking to the X server way too much and flushing _way_ too much, it
seems to me...

Comment 6

[tor]

Attachment: speed up DrawTile for 1-bit alpha images

Comment 7

[tor]

Attachment: small optimization of previous patch

Comment 8

[Boris Zbarsky [:bzbarsky]]

I've filed bug 244862 for equivalent XFT issues.

Comment 9

[tor]

Attachment: make gtk1 happy

Comment 10

[Boris Zbarsky [:bzbarsky]]

That patch speeds up scrolling on that testcase by a factor of 2 or so.

Comment 11

[tor]

Attachment: gtk now also needs transparent areas set to black

Comment 12

[tor]

Checked in.

Comment 13

[Stephen Moehle]

This has caused the regression bug 255703.

Comment 14

[Mats Palmgren (inactive)]

gfx/src/gtk/ has been removed on trunk.
This bug doesn't look like a branch candidate to me.

-> WONTFIX

Comment 15

[Boris Zbarsky [:bzbarsky]]

This bug is alive and well on trunk.  The hotspots are different (so we should reprofile), but the scrolling is still really crappy with thebes.

Comment 16

[Boris Zbarsky [:bzbarsky]]

It'd be really nice to have the testcase attached to the bug...  Too bad save page, complete doesn't pick up CSS images.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Trunk Profile

Fallback compositing for the win... or lose, as the case may be.  :(

Comment 18

[David E. Ross]

See my comment (13) this date in bug #244862.  

Comment 19

[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 20

[Matt Woodrow (:mattwoodrow)]

No response in over a year, so I'm assuming that this was resolved by retained layers. Closing.

Comment 21

[Martijn Wargers (dead)]

The url has gone too.