The default bug view has changed. See this FAQ.

Fix browser chrome drawing performance with D2D

ASSIGNED
Assigned to

Status

()

Core
Graphics
ASSIGNED
5 years ago
2 years ago

People

(Reporter: bas, Assigned: bas)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Snappy:P1])

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
At the request of Taras I've investigated browser chrome drawing performance when D2D is used, and where the weaknesses are. I'll track the general investigation in this bug and as I go file follow-up bugs on things which can be done to improve the situation. Observations at this point:

- D2D is much more CPU intensive than GDI for chrome drawing.
- Texture creation is the most significant contribution. This comes, in descending order of expensiveness, from: Gradient realization textures, D2DLayer textures and PushGroup/PopGroup pairs.
- ComputerMaskAlpha is the most significant graphics contribution on GDI, and ranks fairly high on D2D, but lower than the above listed.

The causes here are:

Gradient realization textures - These are mostly caused by background gradients in browser chrome element.

D2DLayer - These are used to support complex (i.e. non-rectangular) clips.

PushGroup/PopGroup - A bunch of different operations in the tree.

Asides from changing the UI to reduce some of these elements, the following could change inside graphics/layout to improve things:

Gradient realization textures - Enable thebes-azure so that gfxPattern caches its GradientStops object. Then we can try to cache gfxPatterns in layout land for things commonly drawn. These take roughly 16K of VRAM each.

D2DLayer - Reducing the usage of complex clips and caching/reusing ID2D1Layer objects for different complex clips.

PushGroup/PopGroup - Use a cached temp surface of a 'true' push system rather than the create-destroy these translate in for the stateless cairo-surface backend.

Updated

5 years ago
Blocks: 721273
Whiteboard: [Snappy:P1]
(Assignee)

Comment 1

5 years ago
Created attachment 620105 [details]
Screenshot of UI without gradients and only solid borders

Just for reference a screenshot of how a hacked build looks that only does solid rectangular borders and solid colors for gradients.
(Assignee)

Comment 2

5 years ago
See a test build here:

http://people.mozilla.org/~bschouten/firefox-15.0a1.en-US.win32.zip

This is a build which does 3 things:

- Uses a cache for D2DLayers
- Draws all borders as rectangles in the width and color of the 'first' border.
- Draws all gradients as solid colors of the last gradient stop.

It was built with enable-profiling. I can try to add symbols if need be.

Comment 3

5 years ago
I'm probably saying something obvious or obviously wrong, but: gradients (in general) can be trivially implemented as pixel shaders rather than textures, right? If so, does current infrastructure make it easy or too hard?

Same with borders I guess (except corresponding PS is a bit more difficult for pixel-perfectness, but I've written such shaders in the past).

Apologies if this is unhelpful :)

Comment 4

5 years ago
Couldn't Mark Woodrows his work https://bugzilla.mozilla.org/show_bug.cgi?id=539356 doesn't help here too it improves my bug Performance bug Rendering Windowed Youtube Flash Playback (D2D) with significantly less frame drops i guess it could overall higher Performance in this case too ?
(Assignee)

Updated

5 years ago
Depends on: 761388
(Assignee)

Updated

5 years ago
Depends on: 761393

Updated

5 years ago
Summary: Investigate browser chrome drawing performance with D2D → Fix browser chrome drawing performance with D2D

Updated

5 years ago
Depends on: 764117

Updated

5 years ago
No longer depends on: 761388
Depends on: 791637

Updated

4 years ago
Depends on: 805831

Updated

4 years ago
Blocks: 593680
You need to log in before you can comment on or make changes to this bug.