684776 - A lot slower on IE9 in simple canvas image drawing benchmark

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

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

On the "pre-rendered" test IE9 gets 155K ops/s, we get 25K on my home-made trunk build.

We're CPU-bound on the main thread. It breaks down like this:
-- 30% in the Nvidia driver (8.17.12.6658)
-- 16% in misc stuff (looks like mostly D3D10/dxgi/little bits of kernel)
-- 3% painting (updating the little progress message I guess)
-- about 3% in the JS engine, I think
-- about 3% in quickstubs unwrapping etc
-- 41% in nsCanvasRenderingContext2DAzure::DrawImage, which breaks down further:
  -- 27% in nsLayoutUtils::SurfaceFromElement (!)
  -- 11% in DrawTargetD2D::DrawSurface

So nsLayoutUtils::SurfaceFromElement looks like the culprit. Our image cache isn't working? Almost all of SurfaceFromElement is spent flushing D2D.

Comment 1

[Benoit Jacob [:bjacob] (mostly away)]

FYI, any SurfaceFromElement performance improvement would also benefit WebGL as it's called by webgl.texImage2D(dom element).

Comment 2

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

OK, so we don't cache canvases in CanvasImageCache...

The D2D flush under nsLayoutUtils::SurfaceFromElement is 25% of the profile. It's probably happening fromnsCanvasRenderingContext2DAzure::GetThebesSurface (the stack isn't clear). I'm not sure why that flush is so expensive though ... the "can2" canvas doesn't get drawn to during the test.

I guess we could optimize it away by maintaining our own dirty-surface flag, but why is that necessary?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> OK, so we don't cache canvases in CanvasImageCache...

We could likely fix that if we cared, right?  Or is the problem detecting when the surface has changed?

Comment 4

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

We certainly could fix it, but yes, we'd have to be careful about detecting when the canvas has changed and evicting it. That's probably the right way to go, though.

Comment 5

[Guilherme Lima]

Nightly 21
render: 13,268 ±1.98%
pre-rendered: 85,491 ±1.86%

IE9
render: 16,349 ±3.59%
pre-rendered: 94,864 ±1.28%

GC24
render: 285,897 ±3.58%
pre-rendered: 324,095 ±3.10%

Firefox is on par with IE9 but a lot slower then Chrome

Comment 6

[Boris Zbarsky [:bzbarsky]]

That's because the benchmark is stupid to the point of uselesness.  A browser can be really fast at it by just not painting, which is what Chrome does in this case.

Comment 7

[Guilherme Lima]

And how Chrome knows it doesn't have to paint? It this useful in real cases on the web? (asking because I'm a just a user, not a developer)

Comment 8

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

(In reply to Boris Zbarsky (:bz) from comment #6)
> That's because the benchmark is stupid to the point of uselesness.  A
> browser can be really fast at it by just not painting, which is what Chrome
> does in this case.

I'm not sure what you meant there.

I think the issue here is that Skia's stroking code is way faster than D2D's, and our canvas->canvas blending path is not very good either.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> I'm not sure what you meant there.

Last I checked, Chrome just records drawing commands and actually draws them sometime later, no?

How does stroking come in here?  I thought this was a drawImage benchmark?

Comment 10

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

(In reply to Boris Zbarsky (:bz) from comment #9)
> > I'm not sure what you meant there.
> 
> Last I checked, Chrome just records drawing commands and actually draws them
> sometime later, no?

Ah yes, that's a good point. IE10 is doing that too. There actually is a performance win for multicore machines since the canvas rendering can happen on a different thread. So the benchmark isn't entirely bogus if you keep in mind that it measures main-thread utilization rather than actual "drawing speed" --- which of course nobody will :-).

> How does stroking come in here?  I thought this was a drawImage benchmark?

"render" is doing stroking. "pre-rendered" is drawImage with a canvas source.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Ok.  Sounds like we should possibly have three separate bugs blocking this one:

1)  Faster compositing of a canvas
2)  Faster stroking (possibly covered by existing graphics back-end bugs?)
3)  Doing that sort of stuff off-thread

Comment 12

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

Filed bug 832813. That's really all that's needed for this particular benchmark I think.