Closed Bug 379834 Opened 15 years ago Closed 14 years ago

Scrolling with large div using 1px dotted border extremely slow

Categories

(Core :: Layout, defect, P3)

x86
Windows XP
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: vlad)

References

()

Details

(Keywords: perf, regression, testcase, Whiteboard: [dbaron-1.9:RzCo])

Attachments

(3 files)

Attached file 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.
Flags: blocking1.9?
Keywords: perf
Duplicate of this bug: 380133
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.
Another page that is extremely affected by this, I think:
http://blog.reprap.org/2006_03_01_archive.html
Flags: blocking1.9? → blocking1.9+
Blocks: 382392
Duplicate of this bug: 382392
Attached patch workaroundSplinter Review
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.
Assignee: nobody → vladimir
Status: NEW → ASSIGNED
Attachment #266684 - Flags: review?(roc)
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
Could you perhaps mention the bug number where you'll be working on the real fix?
No longer blocks: 382392
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 382392
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!
Blocks: 386944
Whiteboard: [dbaron-1.9:RzCo]
Vlad, do you have a bug filed on the "real fix"?
Was fixed (the real way) a while back -- there is a create region from list of rectangles call that is used now.
Status: REOPENED → RESOLVED
Closed: 15 years ago14 years ago
Resolution: --- → FIXED
Attached file 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!
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
I fixed this upstream in cairo; we'll get it when I do a cairo sync (tomorrow, probably).
This should be significantly better now, though there's an additional fix coming with yet another cairo upgrade.  Reopen if it's still horrible.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
(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.

You need to log in before you can comment on or make changes to this bug.