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.
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.
See a test build here:
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.
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 :)
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 ?