405740 - Very slow scrolling on wikipedia pages

Status: VERIFIED FIXED

(Core :: Graphics, defect, P3)

Description

[Boris Zbarsky [:bzbarsky]]

I finally got tired of the molasses-like scrolling on wikipedia and debugged it.  The problem seems to be that wikipedia puts a border on the left, top, and bottom of the main article div but NOT on the right.  The testcase in the URL field basically has the styles they use, though they use a gray color.

Unfortunately, when we try to scroll with those styles we attempt to bring the X server to its knees via XRenderCompositeTrapezoids.

If I change the "border-right-style: none" to "border-right-width: 0px", which should render the same exact way, the slowness goes away.

This might be Linux-only, since shaver says things are peachy for him in Windows.

Comment 1

[Martijn Wargers (dead)]

For me on windows, it's also slower (or at least taking more cpu) on trunk than on branch.

Comment 2

[Boris Zbarsky [:bzbarsky]]

One of the really slow parts seems to be the gfxContext::Clip() we do when we detect multiple border passes in DrawBorders.

And I bet that's slow because oRect is the size of the div.  In other words, 13000px tall in this case.

The code is assuming that we're already clipped to aDirtyRect, but it seems that that doesn't affect clip operations.  Should it?  If not, should we be intersecting the clip rect with the dirty rect before doing the clip?  That seems like a safe thing to do to me...

For that matter, why do we need this clip to oRect in the multi-pass case, exactly?

Apart from all that, we probably don't actually need multiple passes in this testcase, do we?  Just treating the "none" style as equivalent to one of the other styles, with a width of 0, should work, I would think.  It doesn't quite when I try hacking NumBorderPasses accordingly, because of the way the style is selected at the end of DrawBorders.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Oh, to quantify "slowness".  When we're doing one-pass border drawing the testcase in question, my CPU is at 10% during scrolling, and we scroll smoothly.

When we're doing 4-pass, the CPU is at 100% and we still scroll only about 50% as fast as we should.  I'm basing that on the fact that after I let go of the down arrow key we keep scrolling for about as long as I had it down to start with.  So at least a factor of 20 performance difference as far as I can tell.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Oh, the original test page was http://en.wikipedia.org/wiki/Albert_einstein

Comment 5

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

We should definitely clip the the dirty rect; I assumed that was already happening much earlier in the code.  The reason the clip is needed is that when PushGroup() is called, the temporary surface that's created is the size of the current clip region.  However, that's intersected with the size of the current target surface, so we still shouldn't be creating a 13k tall temporary surface.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So it looks like the clip to oRect is not what's slow.  In particular it's not the clip that hits composite_trapezoids.  The clip that does that is the clip to whatever DoSideClipSubPath generates.

After we do that clip, the clip on the cairo gstate is:

$15 = {mode = CAIRO_CLIP_MODE_REGION, surface = 0x8a58838,
       surface_rect = {x = 8, y = 0, width = 801, height = 673}, serial = 3,
       region = {rgn = {extents = {x1 = 8, y1 = 0, x2 = 809, y2 = 673},
                        data = 0x0}},
       has_region = 1, path = 0x0}

Presumably we're clipping to a trapezoidal path and cairo ends up having to represent that as an image surface?

For what it's worth:

(gdb) p ((cairo_xlib_surface_t*)gstate->clip.surface)->width
$21 = 801
(gdb) p ((cairo_xlib_surface_t*)gstate->clip.surface)->height
$22 = 673

Which seems perfectly reasonable...  I'm not sure why it ends up being so slow.

Comment 7

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(In reply to comment #2)
> Apart from all that, we probably don't actually need multiple passes in this
> testcase, do we?  Just treating the "none" style as equivalent to one of the
> other styles, with a width of 0, should work, I would think.  It doesn't quite
> when I try hacking NumBorderPasses accordingly, because of the way the style is
> selected at the end of DrawBorders.

Yeah, this is correct I think; the code just doesn't do a good job of handling STYLE_NONE.  I'm going to try to fix that.

I think that the clip isn't the problem; the code should just recognize that style NONE is ignorable and treat that as a 0, with appropriate handling in the other cases.  That way we shouldn't hit the 4-pass case, and we avoid DoSideClipSubPath entirely

Comment 8

[Boris Zbarsky [:bzbarsky]]

Well, the thing is that the clip is still easy to hit: just have different colors for the sides.  So if we can make that clip faster, that would still help in all sorts of cases...

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

Vlad: was this supposed to be wanted-next+?

Comment 10

[Boris Zbarsky [:bzbarsky]]

For what it's worth, this bug is basically making Wikipedia unusable for me on trunk; it's one of the bugs preventing me from using trunk altogether...

If there is any chance of us ever fixing this in a dot release (or even for 1.9 initial), I think we should.

Comment 11

[Paweł Kondzior]

How about this bug https://bugzilla.mozilla.org/show_bug.cgi?id=424308 ? Maybe this is related?

Comment 12

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

This is definitely blocking 1.9.1, and if a safe enough patch is done, I think we should take it for 1.9.0.x.  I'll work on it, but it won't be ready for 1.9.0.1 for sure.

Comment 13

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

I am pretty sure this is fixed by bug 424423; please reopen if that's not the case.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So I retested again.  With a tip Firefox mozilla.org build scrolling is molasses-slow even if I go to an all-solid border on the testcase in the URL bar....  Though the X server CPU usage is certainly a lot less.

I have no idea how to get a non-laggy response from GTK2 apps at this point: they're _all_ this laggy on this FC9 install.  So at least we're no worse than the rest.  Or something.

Comment 15

[Tony Chung [:tchung]]

hi bz, can you try retesting again on latest trunk and 1.9.1 branch build?  Your test url is wfm, so i'm unsure if you still see it or not in your environment.  Trying to get this bug verified on both trunk and branch.   Thanks.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Tony, I doubt anything has changed since comment 14.  I'll see what I can do about retesting if you really want me to, but at this point that involves me digging the relevant computer out of a closet and so forth...  I haven't been using it since May.

Comment 17

[Tony Chung [:tchung]]

Im trying to figure out where the tests are for bug 424423.  I'll verify this bug once that one can be verified.

Comment 18

[Tony Chung [:tchung]]

bug 424423 has been verified, and thus this one too. 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090304 Shiretoko/3.1b3pre Ubiquity/0.1.5

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090304 Minefield/3.2a1pre