596746 - Investigate painting performance for Sand Trap chrome experiment

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[David Humphrey (:humph)]

Spin-off bug from bug 596707...the Sand Trap chrome experiment is really CPU heavy for me, more so for us than Chrome.  Both of us are spending most of our time doing colour stuff, but it's interesting to see the differences:

Minefield:
----------------------------------------------------------
27.8%    27.8%    CoreGraphics    argb32_sample_ARGB32
0.0%    27.8%    CoreGraphics     argb32_image_mark
0.0%    27.8%    CoreGraphics      argb32_image
0.0%    27.8%    libRIP.A.dylib       ripl_Mark
0.0%    27.8%    libRIP.A.dylib        ripl_BltImage
0.0%    27.8%    libRIP.A.dylib         ripc_RenderImage
0.0%    27.8%    libRIP.A.dylib          ripc_DrawImage
0.0%    27.8%    CoreGraphics           CGContextDrawImage
0.0%    27.8%    XUL            _cairo_quartz_draw_image
0.0%    27.8%    XUL             _cairo_quartz_surface_fill
0.0%    27.8%    XUL              _cairo_surface_fill
0.0%    27.8%    XUL               _cairo_gstate_fill
0.0%    27.8%    XUL                _moz_cairo_fill_preserve
0.0%    27.8%    XUL                nsCanvasRenderingContext2D::DrawImage(..)
21.2%    21.2%   CoreGraphics    argb32_sample_argb32
0.0%    21.2%    CoreGraphics     argb32_image_mark
0.0%    0.0%    CoreGraphics     argb32_image
0.0%    0.0%    libRIP.A.dylib      ripl_Mark
0.0%    0.0%    libRIP.A.dylib       ripl_BltImage
0.0%    0.0%    libRIP.A.dylib        ripc_RenderImage
0.0%    0.0%    libRIP.A.dylib         ripc_DrawImage
0.0%    0.0%    CoreGraphics          dle_ExecuteDisplayList
0.0%    0.0%    CoreGraphics           dle_Execute
0.0%    0.0%    CoreGraphics            CGDisplayListDelegateExecute    
0.0%    0.0%    libRIP.A.dylib             ripc_TilePattern
0.0%    0.0%    libRIP.A.dylib              ripc_GetColor
0.0%    0.0%    libRIP.A.dylib               ripc_Render
0.0%    0.0%    libRIP.A.dylib                ripc_DrawPath
0.0%    0.0%    CoreGraphics                 CGContextDrawPath
0.0%    0.0%    CoreGraphics                  CGContextFillPath
0.0%    0.0%    XUL                   _cairo_quartz_surface_fill
0.0%    0.0%    XUL                    _cairo_surface_fill
0.0%    0.0%    XUL                     _cairo_gstate_fill
0.0%    0.0%    XUL                      _moz_cairo_fill_preserve
0.0%    0.0%    XUL                    nsCanvasRenderingContext2D::DrawPath(..)

Chrome:
----------------------------------------------------------
34.0%    34.0%    CoreGraphics    sseCGSBlendXXXX8888
0.0%    34.0%    CoreGraphics     argb32_image
0.0%    17.2%    libRIP.A.dylib      ripd_Mark
0.0%    17.2%    libRIP.A.dylib       ripl_BltImage
0.0%    17.2%    libRIP.A.dylib        ripc_RenderImage
0.0%    17.2%    libRIP.A.dylib         ripc_DrawLayer
0.0%    17.2%    CoreGraphics          CGContextDrawLayerAtPoint
0.0%    16.8%    libRIP.A.dylib      ripl_Mark
0.0%    16.8%    libRIP.A.dylib       ripl_BltImage
0.0%    16.8%    libRIP.A.dylib        ripc_RenderImage
0.0%    16.8%    libRIP.A.dylib         ripc_DrawImage
0.0%    16.8%    CoreGraphics          CGContextDrawImage

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.  They're ending up in the fast optimized codepath inside argb32_image whereas we end up with the slow resize-or-something codepath.  Why?

Comment 2

[Markus Stange [:mstange]]

I think the Chrome profile only shows blitting the completed content layer to the window. The actual canvas rendering takes place in a different process whose profile looks very similar to ours.

Comment 3

[Markus Stange [:mstange]]

Attachment: comparison of profiles

This shows Firefox, Safari and Chrome profiles in Bottom-Up mode with call-stack mining on canvascontext.fillRect.

Comment 4

[Bas Schouten (:bas.schouten)]

This is not really relevant anymore.