763119 - OS X canvas text performance is worse than Safari

Status: NEW

(Core :: Graphics, defect)

Description

[Jeff Muizelaar [:jrmuizel]]

On the following test page:
http://jsperf.com/canvas-2d-filltext-performance/2

We get 42,199 Safari and Chrome both get 143,102

There should be some easyish things that should get us at least a little better.

Comment 1

[Benoit Girard (:BenWa)]

Profile:
http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv95MZ5WYjxSlY8y4IogObR4qgNsZxz4dd8M4I7VsDPikd852zW_IMPG1Z93Q1g5gJQiui7SgzurPrb7THr3SJnTy5v-3g9Csv_DK9V-mVl7VkxGk6uDIAY467YfM_0mMPwGN5qnslw3Cp7oG0TjQsrniMVyKoQ

We're spending a lot of time in MakeTextRun, the profiler bottleneck resembles bug 762710.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Attachment: Some easy low hanging fruit

Comment 3

[Jonathan Kew [:jfkthame]]

Both this profile and bug 762710#c3 suggest that the telemetry calls in gfxFont::GetShapedWord are much too expensive. I think we need to substantially simplify (or even completely eliminate) the telemetry here.

Comment 4

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> Both this profile and bug 762710#c3 suggest that the telemetry calls in
> gfxFont::GetShapedWord are much too expensive. I think we need to
> substantially simplify (or even completely eliminate) the telemetry here.

Interestingly, I didn't see that stuff showing up when profiling with instruments.

Comment 5

[John Daggett (:jtd)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> Both this profile and bug 762710#c3 suggest that the telemetry calls in
> gfxFont::GetShapedWord are much too expensive. I think we need to
> substantially simplify (or even completely eliminate) the telemetry here.

Um, the problem here is the text run code is 3x slower than Chrome/Safari.  Removing the problem with Histogram::Add still leaves us 3x slower.  Given that the test is iterating with the same string and font style, which should be cached, our perf with real usage patterns is probably actually worse compared to Safari/Chrome.

Comment 6

[John Daggett (:jtd)]

Another thing to note is that our relative perf is *much* worse on Windows.  Using a test that varies the string drawn each time and draws it into the viewport (rather than off-viewport for the most part), I get the results below.

http://people.mozilla.org/~jdaggett/tests/canvastext-timing.html

fillText ops per second (Win7):

Chrome 21 dev     119,646
IE9                30,190
Nightly (6/10/12)   5,515

Comment 7

[Jeff Muizelaar [:jrmuizel]]

Attachment: Disable subpixel AA on canvas

Safari/Chrome don't do it so we probably shouldn't either.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

Attachment: Use a stack array of for temporary buffers

Comment 9

[Jeff Muizelaar [:jrmuizel]]

Attachment: Add a cache of the last CGColorRef used

Comment 10

[Jeff Muizelaar [:jrmuizel]]

With all of the patches I've posted we now spend more time in SetText() than DrawText() (29% vs 28%)

Comment 11

[John Daggett (:jtd)]

I should also point out here that this isn't a strictly an apples to apples comparison, since we have a single, unified text rendering path while Webkit has a fast-path mode and a significantly slower complex text path.

Default path:

  http://localhost/~jd/tests/canvastext-timing.html

  Nightly:  16,131 ops/sec  (== 0.36x Chrome)
  Chrome21: 45,405 ops/sec

With 'text-rendering: optimizeLegibility' set on the canvas element:

  http://localhost/~jd/tests/canvastext-timing-text-rendering.html

  Nightly:  16,131 ops/sec  (== 1.75x Chrome)
  Chrome21:  9,206 ops/sec

Timings done on OSX 10.5.8.