liquid characters demo is very slow

NEW
Unassigned

Status

()

Core
Canvas: 2D
8 years ago
3 years ago

People

(Reporter: blizzard, Unassigned)

Tracking

(Depends on: 1 bug, {perf})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: parity-chrome, [chromeexperiments], URL)

(Reporter)

Description

8 years ago
Don't know what the bottleneck here is, will need some xperf or shark-looking.
(Reporter)

Updated

8 years ago
Keywords: perf
Whiteboard: parity-chrome
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.
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.
Summary: liquid particles demo is very slow → liquid characters demo is very slow
Duplicate of this bug: 589285
Depends on: 589285

Updated

7 years ago
Duplicate of this bug: 598831
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?
> 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?
CC'ing Bas...
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.
Whiteboard: parity-chrome → parity-chrome, [chromeexperiments]
Is either of those something feasible in the 2.0 timeframe?
(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.
With Azure enabled (gfx.canvas.azure.enabled) we're even much slower than it used to be. (using Gecko/20110701 Firefox/7.0a1)
(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

7 years ago
For me, Azure enabled give me more performance too, no much, but its clearly faster
(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% .
(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.

Updated

6 years ago
QA Contact: canvas.2d → bas.schouten

Comment 16

5 years ago
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 (?).

Updated

3 years ago
Duplicate of this bug: 1122739
See Also: → bug 1122739
You need to log in before you can comment on or make changes to this bug.