504920 - peacekeeper "complex graphics" measures much slower on windows than mac

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Robert Sayre]

It's rare to have traced code show big slowdowns on different platforms. I'm blaming gfx until proven otherwise.

Comment 1

[Joe Drew (not getting mail)]

How does it compare on Linux? I'd expect Linux/Windows to be very comparable if it's gfx/pixman related.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

"Complex graphics" is made up of two basic tests:

ripples.js:
 - basically just does a bunch of fillRects()

experimentalMovie.js:
 - draws an image
 - draw a bunch of slices of the image
 - draws a gradient mask on top()

The first step will be figuring out which of these tests shows the difference between mac and windows.

Rob, do you know a way to run these tests individually? How much of a difference did you see between the results?

Comment 3

[Robert Sayre]

http://hg.mozilla.org/users/mpalmgren_mozilla.com/peacekeeper/

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

(Guys, just run the tests and see for yourself -- Rob is hardly an unreliable source for this stuff!)

Comment 5

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #4)
> (Guys, just run the tests and see for yourself -- Rob is hardly an unreliable
> source for this stuff!)

I didn't know of a way to run the individual tests until Rob's post 11min ago...

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

SOrry, yes, I misread your comment.  I stand by my endorsement of Rob as a source, though! :-P

Comment 7

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Any progress here?  To whom should this bug be assigned?

Comment 8

[Joe Drew (not getting mail)]

No progress that I know of. If Jeff's interested in investigating it, it'd fall under his purview as the make-cairo-faster dude.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

I had results comparing these test on windows vs. os x but my browser hung...

Here's approximately what they were:

Windows
experimentalMovie
10ops
experimentalRipple01
10ops
experimentalRipple02
4ops


OS X
experimentalMovie
25ops
experimentalRipple01
4ops
experimentalRipple02
2ops

So it looks like the difference is in experimentalMovie

Comment 10

[Robert Sayre]

Where did you hang? Any profile data?



------------------------------

504920 status [www.mailtothefuture.org]

https://bugzilla.mozilla.org/show_bug.cgi?id=504920

----------

this is a message from the past. the message was sent on 2009.07.23 01:20:43.

www.mailtothefuture.org

Comment 11

[Jeff Muizelaar [:jrmuizel]]

The hang was not on the machine running peacekeeper and was someplace in layout.
Activity monitor hung on me after that, so I lost that data too.

It looks like the reason this is slow on windows is because of surface migration.
We are spending nearly half of the total cpu time in BitBlt.

Presumably what's happening here is that the source image is DDB and we need to get it back (BitBlt) from the kernel when we want to use it as a source when drawing on the canvas.

Comment 12

[Robert Sayre]

Got a reminder on this today. Any progress?

--------------------

https://bugzilla.mozilla.org/show_bug.cgi?id=504920

----------

this is a message from the past. the message was sent on 2009.07.31 02:23:07.

www.mailtothefuture.org

Comment 13

[Damon Sicore (:damons)]

Jeff, this looks like one of those perf issues we should be pushing on.  Is there any reason we aren't digging into this ASAP?

Comment 14

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #13)
> Is there any reason we aren't digging into this ASAP?

SIGGRAPH was the reason last week.

However, it looks like this should've been fixed with 455513 but part of that patch never landed. I'll have a patch today.

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use SetCanConvertToDIB(PR_TRUE) when creating optimized image surfaces

Comment 16

[Jeff Muizelaar [:jrmuizel]]

Comment on attachment 393776 [details] [diff] [review]
Use SetCanConvertToDIB(PR_TRUE) when creating optimized image surfaces

This patch is very similar to the original patch at bug 455513. However it sets SetCanConvertToDIB in Optimize instead of in Init though maybe it should be in Init too.

This changes the performance of experimentalMovie to about 24ops which matches OS X

Comment 17

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

Comment on attachment 393776 [details] [diff] [review]
Use SetCanConvertToDIB(PR_TRUE) when creating optimized image surfaces

looks good, but send it to try server?

Comment 18

[Robert Sayre]

Comment on attachment 393776 [details] [diff] [review]
Use SetCanConvertToDIB(PR_TRUE) when creating optimized image surfaces

does this compile without warning?

Comment 19

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use cairo_set_can_convert_to_dib(TRUE) when creating optimized image surfaces

A simplified version of the previous that avoids exporting the api to thebes and avoids any different bool type issues (even if they weren't causing warnings).

Comment 20

[Jeff Muizelaar [:jrmuizel]]

http://hg.mozilla.org/mozilla-central/rev/ca46dd208b99

Also includes fix to the cairo patch so that the build doesn't break on winmo.