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.
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
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.
11 years ago
Could you perhaps mention the bug number where you'll be working on the real fix?
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.
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!
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.
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!
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).
10 years ago
This should be significantly better now, though there's an additional fix coming with yet another cairo upgrade. Reopen if it's still horrible.
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.
(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.