379834 - Scrolling with large div using 1px dotted border extremely slow

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Martijn Wargers (dead)]

Attachment: testcase

The mentioned url has become much slower in scrolling, also focusing links and selecting seems to have become slower.
This regressed between 2007-04-30 and 2007-05-01, regression of bug 368247.

The testcase has a test that measures the time it takes to scroll a certaint amount:
5391ms 1.8 branch build SeaMonkey of 2007-01-11
6266ms 3007-04-30 trunk Firefox build
74500ms 3007-05-03 trunk Firefox build (consuming 100% cpu)

This is all tested on windowsXP.

Comment 2

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

This will get much much better with a new cairo upgrade, which has some massive performance improvements in this case.  I'll get to that asap.

Comment 3

[Martijn Wargers (dead)]

Another page that is extremely affected by this, I think:
http://blog.reprap.org/2006_03_01_archive.html

Comment 5

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

Attachment: workaround

This is a workaround, but it's also a fix -- there's no downside to this.  The problem is actually not a cairo upgrade turns out:

17:11 < cworth> vlad_: Oh, I think I know exactly what your bug is, (since I
                just ran into this recently).
17:11 < cworth> vlad_: The rectangle optimization involves extracting a region
                from the list of trapezoids.
17:12 < cworth> vlad_: And the current cairo code is stupidly constructing a
                region by successively performing Union on the region.
17:12 < vlad_> Oh.
17:12 < vlad_> that would explain the exponential slowdown!
17:12 < cworth> vlad_: Instead, there should be a
                "create_region_from_list_of_rectangles" call.
17:13 < cworth> vlad_: Indeed. (Or at least O(N*N)).
17:13 < cworth> vlad_: I started a fix a week or two ago, but I didn't get it
                to past the test suite quite yet.

I'll work on the real fix afterwards, but this'll close off this bug for a5.

Comment 6

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

Checked in.

Comment 7

[Martijn Wargers (dead)]

Could you perhaps mention the bug number where you'll be working on the real fix?

Comment 8

[Martijn Wargers (dead)]

Also, this isn't fixed for me.
With a 2007-06-02 build, I get as result: 8516ms. That's still appr. 50% slower than it used to be.

Comment 9

[Gábor Stefanik]

That isn't really this bug, that might be another performance regression This one was much worse, it jumped from 6266 ms to 74500 ms!

Comment 10

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

Vlad, do you have a bug filed on the "real fix"?

Comment 11

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

Was fixed (the real way) a while back -- there is a create region from list of rectangles call that is used now.

Comment 12

[Martijn Wargers (dead)]

Attachment: testcase2

This testcase uses 25 dotted borders.
With a branch build I get as result: 13732ms
With a trunk build I get as result: 39356ms
That's almost 3 times as slow!

Comment 13

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

The continuing fix of this is an upstream cairo bug -- basically, the dotted/dashed stroker is doing a whole bunch of extra work for path segments that are outside of the clip bounds.  Also, the dashed/dotted stroke code could be optimized itself.

Comment 14

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

I fixed this upstream in cairo; we'll get it when I do a cairo sync (tomorrow, probably).

Comment 15

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

This should be significantly better now, though there's an additional fix coming with yet another cairo upgrade.  Reopen if it's still horrible.

Comment 16

[Martijn Wargers (dead)]

With a branch build I get: 13915ms
With current trunk build I get: build:8918ms

So this seems indeed fixed now (and even faster!)
Thanks!
Although the testcase in this bug still suffers from bug 417543, I doubt that makes a difference on performance.

Comment 17

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

(In reply to comment #16)
> With a branch build I get: 13915ms
> With current trunk build I get: build:8918ms
> 
> So this seems indeed fixed now (and even faster!)
> Thanks!
> Although the testcase in this bug still suffers from bug 417543, I doubt that
> makes a difference on performance.

It actually does, though it shouldn't e hugely significant.  I suspect when I do the cairo upgrade, the numbers will get back close to 1.8 speed unfortunately.  But please retest when that lands.