523298 - Much slower than Chrome in demo due to temporary surfaces in background image painting

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

On the following demo

http://mrdoob.com/projects/chromeexperiments/depth_of_field/

we are getting badly beaten by chrome. Not actually sure if this is due to javascript issues, or canvas issues. Guessing canvas for now, but we really need profiles.

However I think that drawImage currently makes us always fall off trace because of the way that the optional arguments work. Bug 459452 might fix that.

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Actually, this isn't canvas at all since it's not using canvas. Seems like this is simply a load of absolutely positioned elements combined with CSS-sprite and transforms (to do scaling).

So also not bug 459452 as there is no drawImage calls.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Basic breakdown from a shark profile:

52% under background painting (and yes, transforms are involved).
20% (!) vm_fault

If I exclude the supervisor callstacks, painting is at 80%, 10% is the usual AppKit/HiToolBox event mess, 7% is under js_Interpret.  We don't seem to jit this, in fact, but given the painting that's not exactly the bottleneck.  Might still want a bug on that, of course.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Hmm.  So I just did a malloc trace in shark.  Over 10s, the testcase allocated about 11MB.  2MB of that was painting; the rest was JS.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The painting allocations are from ripl_Create called from ripc_GetColor, called from ripc_Render, called from ripc_DrawRects, called from CGContextFillRects, called from CGContextFillRect,called from CGContextDrawTiledImage, called from _cairo_quartz_surface_paint, called via some cairo stuff from imgFrame::Draw.

The JS allocations are from js_NewStringFromCharBuffer (3.5 MB), js_ValueToString on numbers (2.5MB), js_ConcatStrings (1.6MB).  Also about 500KB under quickstub conversions to string, 140k under ExecuteTree (running regexps).  88KB under js_GetMutableScope (JSScope::create), 70KB under js_SetProperty (JSScope::changeTable).  Other allocations are pretty small all around.

Comment 5

[Boris Zbarsky [:bzbarsky]]

The painting code spends 39% of total testcase time in (not under) sseCGSBlendXXXX8888 in the CoreGraphics library; this is under CGContextDrawTiledImage called from moz_cairo_paint_with_alpha called from imgFrame::Draw.  The moz_cairo_fill_preserve call Draw() does is the other 35+% there; this has no single chokepoint (thought resample_band in CoreGraphics is a lot of it).

Comment 6

[Robert Sayre]

(In reply to comment #4)
> The painting allocations are from ripl_Create called from ripc_GetColor, called
> from ripc_Render, called from ripc_DrawRects, called from CGContextFillRects,
> called from CGContextFillRect,called from CGContextDrawTiledImage, called from
> _cairo_quartz_surface_paint, called via some cairo stuff from imgFrame::Draw.

Instruments showed 95% of allocations coming from here.

Comment 7

[Robert Sayre]

Attachment: Instruments screenshot

Comment 8

[Jeff Muizelaar [:jrmuizel]]

The Safari GFX call stacks look pretty different:

One of the big differences is that we use CGContextDrawTiledImage whereas Safari uses CGContextDrawImage. Also interesting is that sseCGSBlendXXXX8888 doesn't even show up in Safari.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The testcase is using background-position and transforms, so I suspect image drawing is going through the path where we create a temporary image which is the piece of the image we need to render, so we can EXTEND_PAD it and not sample the wrong pixels.

We could test that hypothesis by replacing !subimage.Contains(imageRect) with PR_FALSE here:
http://mxr.mozilla.org/mozilla-central/source/modules/libpr0n/src/imgFrame.cpp#535
If that is a big performance issue, then we probably need to cache extracted subimages; exactly how we store them depends on how to maximize performance of the native APIs cairo is using. Or alternatively we could bite the bullet and move forward with adding some kind of subimage API to cairo.

Comment 10

[Robert Sayre]

(In reply to comment #6)
> 
> Instruments showed 95% of allocations coming from here.

Shark malloc trace had something similar to say with "Record Only Active Blocks" unchecked.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Filed bug 523452 on the JSeng part here.

Comment 12

[Boris Zbarsky [:bzbarsky]]

> with "Record Only Active Blocks" unchecked.

Oh, without that it only records the blocks that are still alive after the profile ends, it seems?  Bah!

Comment 13

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #9)
> The testcase is using background-position and transforms, so I suspect image
> drawing is going through the path where we create a temporary image which is
> the piece of the image we need to render, so we can EXTEND_PAD it and not
> sample the wrong pixels.

Yeah, that's my guess as well.

Comment 14

[Boris Zbarsky [:bzbarsky]]

I tried the suggestion in comment 9 paragraph 2.  That dropped the paint time from 80% to 53% with supervisor callstacks hidden, and dropped vm_fault from 20% to 2%.  The animation also looks much smoother.  There seems to be no more moz_cairo_paint_with_alpha under imgFrame::Draw.

Comment 15

[Joe Drew (not getting mail)]

WebKit is drawing the images as background tiles at 1:1 scale, then somehow scaling down the rendered image according to the transform. (They also clip the destination image when they're drawing sprites, rather than use source clipping.)

Comment 16

[Carlos Alén Silva]

FWIW,

1. Open http://mrdoob.com/projects/chromeexperiments/depth_of_field/ with Opera...
2. ???
3. Profit!

It's fast!

Comment 17

[Boris Zbarsky [:bzbarsky]]

(In reply to comment #14)
> I tried the suggestion in comment 9 paragraph 2.  That dropped the paint time
> from 80% to 53%

Or put another way made the testcase about 2.5 times faster...  Seems like the tail end of comment 9 might be worth looking into.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Still much faster in Chrome than Firefox trunk. Testing on Win7 w/ D2D enabled.

Comment 19

[Mayank Bansal]

Much smoother in IE10 , compared to Chrome.

Comment 20

[Gregory Pappas [:gregp]]

This demo performs great now.