Closed Bug 328374 Opened 14 years ago Closed 12 years ago

DHTML performance regression because of cairo

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: martijn.martijn, Assigned: vlad)

References

()

Details

(Keywords: perf, regression, testcase)

Attachments

(1 file)

The url is from bug 277762.
I'm using a Duron 800MHz, NVidia GeForce2 MX 100/200 32MB, screen setting 1024*768 32bit color depth.

To begin the testcase, click on the button "Automatic test for all()".
These are my results:
Results build:       02-22 (non-cairo)  02-23 (cairo)
relative: transpare: 8032               20499
absolute: transpare: 8032               14210
fixed   : transpare: 8032               14140
static  : transpare: 8012               8032
relative: not_trans: 8032               20169
absolute: not_trans: 8032               14070
fixed   : not_trans: 8032               14031
static  : not_trans: 8022               8031
relative: div_block: 8032               10795
absolute: div_block: 8032               8031
fixed   : div_block: 8032               8031
static  : div_block: 8012               8031

As you can see Cairo builds are quite slower than non-Cairo builds.

Static/absolute/fixed/relative means the containing <div> is positioned in that way.
transpare means the image in the background is transparent
not_trans means the image in the background is not transparent
div_block means the background is a green div
Depends on: 328367
Flags: blocking1.9a1?
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060407 Firefox/3.0a1

Have you got any recent numbers? A quick test for me shows that only relative-transpare and relative-not-transpare are slower in cairo-gtk2 vs. gtk2. However, I don't know if that's a difference because your results are from Windows, or because they're a month and a half old :-)
I've tested bug 328367 recently, and that still gave the bad performance, so I'm quite sure this also is not solved for me.
If you're seeing performance issues with this testcase under Linux, please file a new bug for that and mention the bug number here.
Keywords: regression
Depends on: cairoperf
Blocks: cairoperf
No longer depends on: cairoperf
Blocks: 334719
No longer blocks: cairoperf
Vlad, pav, any idea what might be up here?
Not offhand; on my laptop, forced down to 787MHz, I get 8031 for all the tests with a recent trunk windows nightly.  What is the measurement?  Total number of milliseconds that it takes to move the block down, and 8s is the expected result due to timing?
(In reply to comment #4)
> Not offhand; on my laptop, forced down to 787MHz, I get 8031 for all the tests
> with a recent trunk windows nightly.  What is the measurement?  Total number of
> milliseconds that it takes to move the block down, and 8s is the expected
> result due to timing?
Yes, it is indeed in milliseconds. Actually, I'm not sure what the expected result would be, but I would expect a result comparable with a non-Cairo build.
Results I get with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060427 Minefield/3.0a1
Results:
relative: transpare: 19988
absolute: transpare: 14731
fixed   : transpare: 14361
static  : transpare: 8022
relative: not_trans: 18597
absolute: not_trans: 12348
fixed   : not_trans: 12377
static  : not_trans: 8031
relative: div_block: 11336
absolute: div_block: 8032
fixed   : div_block: 8032
static  : div_block: 8032

Note that in the past we've discovered these things to be strongly video-hardware-related in many cases (eg DIB vs DDB perf on different cards, etc).  See bug 277762.  Not sure that's necessarily the case here, of course.

The time it takes to run the testcase on an infinitely fast machine is 400*20 = 8000 ms (400 steps, 20ms timeout).

You could try doing a 10ms timeout locally instead of 20ms...  That might show the bug better.
Blocks: 203448
So this seems to be fixed with the patch from bug 343655!
I've compared between the 2006-08-09 and 2006-08-10 build:
Results in ms:       2006-08-09  2006-08-10
relative: transpare: 14651       8022
absolute: transpare: 9804        8022
fixed   : transpare: 9844        8022
static  : transpare: 8021        8022
relative: not_trans: 13229       8022
absolute: not_trans: 8563        8022
fixed   : not_trans: 8482        8022
static  : not_trans: 8021        8022
relative: div_block: 8021        8022
absolute: div_block: 8021        8022
fixed   : div_block: 8022        8022
static  : div_block: 8022        8021

So with the 2006-08-10 build, I get the results like I used to.
So this bug is basically fixed, but the testcase suffers from bug 348191 currently (transparent gifs that are black).
I want to retest when that bug gets fixed.
Depends on: 343655, 348191
Martijn, can you please retest and give a short feedback.
Attached file testcase, zipped
Sorry for the delay, I actually tested this already some time ago.
It is mostly fixed on my 800MHz computer, however when I increase the amount of elements that are moved, then I still can see a small slow-down in cairo builds.
But I need to test this some more (and just test between cairo and non-cairo builds. I'll try to do that in the next few days.

Results:             ff1.5.0.6  2006-08-13
relative: transpare: 9774       16393
absolute: transpare: 8783       14341
fixed   : transpare: 9353       14460
static  : transpare: 8482       10244
relative: not_trans: 9564       13089
absolute: not_trans: 8482       10115
fixed   : not_trans: 9063       10515
static  : not_trans: 8442       10054
relative: div_block: 9484       12978
absolute: div_block: 8533       10204
fixed   : div_block: 8883       10575
static  : div_block: 8463       9945
Flags: blocking1.9a1? → blocking1.9?
Assignee: nobody → vladimir
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
With 10ms timeout, as suggested in comment #6

Results:             SM1.1.7    FF3.0b5pre
relative: transpare: 9937       6365
absolute: transpare: 7672       6324
fixed   : transpare: 7453       6275
static  : transpare: 7188       6268
relative: not_trans: 9219       6266
absolute: not_trans: 7640       6262
fixed   : not_trans: 7672       6266
static  : not_trans: 7312       6266
relative: div_block: 7750       6266
absolute: div_block: 7688       6571
fixed   : div_block: 7640       6266
static  : div_block: 7140       6657

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b5pre) Gecko/2008031605 Minefield/3.0b5pre

Cairo is now faster
Confirm on Linux:

Results:             Fx1.5   Fx3.0b5pre
relative: transpare: 5977    5028
absolute: transpare: 5935    5572
fixed   : transpare: 5915    5000
static  : transpare: 5939    4980
relative: not_trans: 5927    4977
absolute: not_trans: 5943    5024
fixed   : not_trans: 5934    5027
static  : not_trans: 5923    5007
relative: div_block: 5954    5038
absolute: div_block: 5921    5002
fixed   : div_block: 5943    4997
static  : div_block: 5918    5002

closing as WFM, reopen if MacOS is still slower
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Ok, on branch, with the unminimized testcase, I get:
Results:
relative: transpare: 9171
absolute: transpare: 9297
fixed   : transpare: 9625
static  : transpare: 9312
relative: not_trans: 9094
absolute: not_trans: 9250
fixed   : not_trans: 9407
static  : not_trans: 9078
relative: div_block: 9593
absolute: div_block: 9219
fixed   : div_block: 9204
static  : div_block: 8891

On current trunk, I get:
Results:
relative: transpare: 8123
absolute: transpare: 8088
fixed   : transpare: 8356
static  : transpare: 8035
relative: not_trans: 8271
absolute: not_trans: 8027
fixed   : not_trans: 8041
static  : not_trans: 8251
relative: div_block: 8052
absolute: div_block: 8242
fixed   : div_block: 8603
static  : div_block: 8354

So this indeed seems fixed.
But I don't think trunk is really faster, I suspect timers are working differently on trunk (better).
Status: RESOLVED → VERIFIED
On trunk, timers work better, and JS itself is faster.  The drawing issue this was initially filed on may or may not have been fixed.
You need to log in before you can comment on or make changes to this bug.