564643 - liquid characters demo is very slow

Status: NEW

(Core :: Graphics: Canvas2D, defect)

Description

[Christopher Blizzard (:blizzard)]

Don't know what the bottleneck here is, will need some xperf or shark-looking.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Basic time breakdown on Mac:

9% painting (nsViewManager::Refresh)
3% FillRect on the canvas context from js_Interpret
2% Restore on the canvas context from js_Interpret

The rest of the time is spent on trace poking the canvas:

60% FillText (8% making textruns, 4% invalidation, 2% GetWidth on canvas bidi
              processor, 41% moz_cairo_show_glyphs which is mostly spent in,
              not under, cairo_quartz_surface_show_glyphs).
17% SetFont (6% gfxFontGroup::BuildFontList called from CreateFontGroup,
             4% CSS parser, 2% style computation, 1.5% rulenode GC,
             1.2% ResolveStyleForRules).

The BuildFontList stuff seems to call ResolveFontName, lots of GetService, CompressWhitespace, GetCharPref, AtomImpl::ToUTF8String, etc.

So the obvious thing to try optimizing here is cairo_quartz_surface_show_glyphs, but we should be able to do something about BuildFontList, I hope.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Er, I lied.  The "in, not under" for cairo_quartz_surface_show_glyphs is only if I blame system libs on callers.  If I don't, then it's all time under CGContextShowGlyphsWithAdvances, under draw_glyphs, calling ripc_DrawGlyphs, calling CGGlyphLockLockGlyphBitmaps, etc, etc.  14% of our total time is under CGFontCacheLock.

Looking at the places where time's really spent, 12% is in (not under) equal_strike_key; seems to all be under glyph rendering.

Comment 5

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

Steven says in Bug 598831 that:

> Liquid particles is slower than chrome
> without hardware acceleration, but there is no noticeable
> difference between minefield and chromium with
> hardware acceleration on

So that seems pretty easy to explain: without hw accel, Google is using Skia which is a fast software-based renderer. With hw accel, we're using Direct2D which is fast.

Christopher: can you retry now that Direct2D is enabled by default?

Is it still worth optimizing software rendering, shouldn't we just try to get hw acceleration to the remaining platforms?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> Is it still worth optimizing software rendering,

Given our hardware acceleration blacklist?  Perhaps yes.

Also given the fact that no equivalent to d2d exists on non-Windows at this time... though those may already be following totally different software codepaths.

More importantly, is there something else here that needs speeding up too, given that with d2d we're not _beating_ chrome?

Comment 7

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

CC'ing Bas...

Comment 8

[Bas Schouten (:bas.schouten)]

This has already been profiled for D2D a while ago, not sure where the bug is, Shaver reported it I believe.

There's two things we can do to speed this up:

- Not do OPERATOR_ADD, operator add is slowing this down significantly.
- Draw glyphs by their outline rather than with cleartype and all.

Together these two steps make it very fast. The first however, is obviously incorrect. We might be able to speed this up significantly by 'batching' operator add calls, rather than rendering to a temp surface and blending back separately for each glyph.

The second would probably be fine for Canvas, but we don't have an API to tell cairo to do this currently.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Is either of those something feasible in the 2.0 timeframe?

Comment 10

[Bas Schouten (:bas.schouten)]

(In reply to comment #9)
> Is either of those something feasible in the 2.0 timeframe?

A matter of priorities. Neither is really rocket science.

Comment 11

[Oskar Ivanić (:icecold)]

With Azure enabled (gfx.canvas.azure.enabled) we're even much slower than it used to be. (using Gecko/20110701 Firefox/7.0a1)

Comment 12

[Bas Schouten (:bas.schouten)]

(In reply to comment #11)
> With Azure enabled (gfx.canvas.azure.enabled) we're even much slower than it
> used to be. (using Gecko/20110701 Firefox/7.0a1)

On my machine we're a little faster actually. We use a little more GPU than we need on this Demo though with Azure, so you may be GPU bound (you can check that by seeing if it's using an entire CPU core when running the demo). We can fix this fairly easily but I'm not sure it's worth it short term.

Comment 13

[Theliel]

For me, Azure enabled give me more performance too, no much, but its clearly faster

Comment 14

[Oskar Ivanić (:icecold)]

(In reply to comment #12)
> On my machine we're a little faster actually. We use a little more GPU than
> we need on this Demo though with Azure, so you may be GPU bound (you can
> check that by seeing if it's using an entire CPU core when running the
> demo). We can fix this fairly easily but I'm not sure it's worth it short
> term.

Actually I was running Liquid Particles (original version) where demo took 99% of GPU, so that's the answer why is slow with Azure. 

Liquid Characters uses 10% of GPU without Azure, and with Azure it uses around 40% .

Comment 15

[Bas Schouten (:bas.schouten)]

(In reply to comment #14)
> (In reply to comment #12)
> > On my machine we're a little faster actually. We use a little more GPU than
> > we need on this Demo though with Azure, so you may be GPU bound (you can
> > check that by seeing if it's using an entire CPU core when running the
> > demo). We can fix this fairly easily but I'm not sure it's worth it short
> > term.
> 
> Actually I was running Liquid Particles (original version) where demo took
> 99% of GPU, so that's the answer why is slow with Azure. 
> 
> Liquid Characters uses 10% of GPU without Azure, and with Azure it uses
> around 40% .

That's expected, and a fix is planned although it's not at the top of my priority list.

Comment 16

[RNicoletto]

Windows 7 32-bit
CPU AMD Phenom 8750 Triple Core
4GB RAM
NVIDIA GeForce GTX 560 with latest driver (v. 306.97)

Liquid Particles DEMO tested with both Firefox 17 and latest nightly.
Results:
- with Hardware Acceleration ON, 4-5 FPS;
- with Hardware Acceleration OFF, 15-18 FPS;
- no differences between the two Firefox versions (?).