Closed Bug 504920 Opened 11 years ago Closed 11 years ago
peacekeeper "complex graphics" measures much slower on windows than mac
It's rare to have traced code show big slowdowns on different platforms. I'm blaming gfx until proven otherwise.
How does it compare on Linux? I'd expect Linux/Windows to be very comparable if it's gfx/pixman related.
"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?
(Guys, just run the tests and see for yourself -- Rob is hardly an unreliable source for this stuff!)
(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...
SOrry, yes, I misread your comment. I stand by my endorsement of Rob as a source, though! :-P
Any progress here? To whom should this bug be assigned?
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.
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
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
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.
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
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?
(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 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 on attachment 393776 [details] [diff] [review] Use SetCanConvertToDIB(PR_TRUE) when creating optimized image surfaces looks good, but send it to try server?
Attachment #393776 - Flags: review?(vladimir) → review+
Comment on attachment 393776 [details] [diff] [review] Use SetCanConvertToDIB(PR_TRUE) when creating optimized image surfaces does this compile without warning?
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).
Attachment #393880 - Flags: review?(vladimir) → review+
http://hg.mozilla.org/mozilla-central/rev/ca46dd208b99 Also includes fix to the cairo patch so that the build doesn't break on winmo.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.