Cache rasterized tiled gradients

ASSIGNED
Assigned to

Status

()

defect
ASSIGNED
7 years ago
2 years ago

People

(Reporter: avih, Assigned: avih)

Tracking

(Blocks 1 bug, {perf})

Trunk
x86_64
Windows 7
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Australis:P5][Australis:M-])

Attachments

(3 attachments, 2 obsolete attachments)

Bug 826422 accelerates tiled gradients greatly by drawing the tile once, then using it as a fill pattern for the entire area.

This bug is about caching this single tile raster, which proves to provide further significant speedup (x10 - x20 on relevant scenarios). This bug builds on bug 826422.

Attached is a (incorrect but enough as) proof of concept tiles cache. E.g. it accelerates scrolling from top to bottom using the KB on http://lea.verou.me/css3patterns/ - PaintGradient goes down at the profiler from 18% to less than 1%, and I observed similar speedups on other relevant scenarios.

Bug 743847 is more generic (cache some rasterized gradients).
Bug 772917 is Cairo only.

My approach is to enhance the existing patterns cache, such as some of the cached pattern items will also hold a cached tile raster.

Invalidation policy will probably be dropping LRU item[s]. Number of cached items would either be fixed, or - for better memory usage predictability - limited by overall number of cached pixels.
Enhance and use the patterns cache to also hold tile raster if possibly. Debug patch which enables changing mode using a preference ("default", tile brush, tile brush + caching).

The patterns cache items invalidate soon enough, practically making it roughly equivalent to 10 cached tile rasters at the previous proof of concept patch. This seems enough for most practical cases.
Attachment #707000 - Attachment is obsolete: true
Same as the previous patch with the debug stuff removed. (Note that the previous debug patch defaults to "old" behavior if the pref isn't changed).

Waiting with the r? until bug 826422 lands, as this patch is on top of it.
Attachment #707208 - Attachment is obsolete: true
Posting this patch for reference only. It contains some debug code, and also some more tab-animation debug at tabbrowser.xml (unrelated to gradients cache - but can measure rendering improvements - repeat tab open/close and average measurements).

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #6)
> Comment on attachment 706115 [details] [diff] [review]
> Don't do any of this if pattern->mCoversTile. That's already pretty fast and
> handles non-pixel-aligned tiles perfectly.

Despite the above from bug 826422 comment #6, this patch "tricks" the gradient calculation into setting pattern->mCoversTile=false for cases of strict horizontal/vertical linear gradients, and also caches a 1px tile for each such gradient. This allows, among other cases, to cache tabstrip-tabs gradient tiles (1px wide) and so once cached, all tab animation are just tiling existing cached rasters without any concrete gradients calculations.

The resulting tab animation paint times are almost halved, and temporary memory usage is decreased dramatically (on my specific test pattern, from 500MB with legacy down to 5MB with 1px tiles after several animations).

Interestingly, the speedup is only noticeable when compiler optimizations are enabled. Not sure why.
As for the excessive memory usage with legacy paint, see bug 837542 (possible reasons: too many pattern-cache misses, several different gradients per animation frame, possibly too much data per cache item for the case of tab background).
Depends on: 838758
Whiteboard: [Australis:P?][Australis:M?]
Whiteboard: [Australis:P?][Australis:M?] → [Australis:P5][Australis:M?]
Whiteboard: [Australis:P5][Australis:M?] → [Australis:P5][Australis:M-]
You need to log in before you can comment on or make changes to this bug.