79.10 KB, image/png
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: 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.
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 ?