If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Scrolling with large div using 1px dotted border extremely slow

VERIFIED FIXED

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: Martijn Wargers (dead), Assigned: vlad)

Tracking

({perf, regression, testcase})

Trunk
x86
Windows XP
perf, regression, testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [dbaron-1.9:RzCo], URL)

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
Created attachment 263865 [details]
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?

Updated

11 years ago
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.
(Reporter)

Comment 3

11 years ago
Another page that is extremely affected by this, I think:
http://blog.reprap.org/2006_03_01_archive.html
Flags: blocking1.9? → blocking1.9+
(Reporter)

Updated

11 years ago
Blocks: 382392

Updated

11 years ago
Duplicate of this bug: 382392
Created attachment 266684 [details] [diff] [review]
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.
Assignee: nobody → vladimir
Status: NEW → ASSIGNED
Attachment #266684 - Flags: review?(roc)
Attachment #266684 - Flags: superreview+
Attachment #266684 - Flags: review?(roc)
Attachment #266684 - Flags: review+
Checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Flags: in-testsuite?
(Reporter)

Comment 7

11 years ago
Could you perhaps mention the bug number where you'll be working on the real fix?
(Reporter)

Updated

11 years ago
No longer blocks: 382392
(Reporter)

Comment 8

11 years ago
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 → ---
(Reporter)

Updated

11 years ago
Blocks: 382392

Comment 9

11 years ago
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!
(Reporter)

Updated

10 years ago
Blocks: 386944
Whiteboard: [dbaron-1.9:RzCo]
Vlad, do you have a bug filed on the "real fix"?
Priority: -- → P3
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
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 12

10 years ago
Created attachment 291413 [details]
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!
(Reporter)

Updated

10 years ago
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).
Depends on: 416018
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
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED
(Reporter)

Comment 16

10 years ago
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.