Open Bug 869496 Opened 12 years ago Updated 2 months ago

Accelerate CSS/SVG/custom filters (shaders, GLSL, GPU)

Categories

(Core :: Graphics, enhancement)

enhancement

Tracking

()

People

(Reporter: jwatt, Unassigned, NeedInfo)

References

(Blocks 1 open bug, )

Details

(Keywords: perf)

Our performance on SVG containing filters is often really bad compared to other implementations. In order to fix that, and in order to support performant CSS/custom filters, we're going to want to accelerate filter processing. For more see: https://wiki.mozilla.org/Gecko:AcceleratedFilters
Blocks: 854024
Blocks: 844664
Blocks: 793507
Depends on: 869828
Blocks: 703872
Blocks: 699756
Blocks: 749113
Blocks: 609361
Blocks: 601131
Blocks: 483868
Markus, what still needs to happen here, and is there any sort of schedule?
Flags: needinfo?(mstange)
No longer blocks: 609361
There is no schedule at the moment. Here's my understanding of the remaining work: - Phase I: Basic layers support for filters: - Give filters their own nsDisplayItem type, e.g. nsDisplayFilter - Give ContainerLayers a filter attribute and make nsDisplayFilter build a ContainerLayer with the attached filter - When building the layer, also attach additional feImage images and FillPaint/StrokePaint images to the layer somehow - Figure out how FilterDescription coordinates (like primitive subregions), which are in filter space at the moment, can be translated into layer pixel coordinates - Have nsDisplayFilter use layer state LAYER_INACTIVE instead of LAYER_SVG_EFFECTS and let the BasicLayerManager do the filter rendering, based on the layer's filter attribute - Phase II: Accelerated filter rendering on the compositor - Teach our Compositors how to do filter rendering - BasicCompositor: easiest, about the same code as BasicLayerManager - D3D: probably not that hard, just need to get a DrawTargetD2D1 for the D3D render target and use our existing FilterSupport infrastructure to render using FilterNodeD2D1 - CompositorOGL: hardest - Investigate using SkiaGL for filter rendering - Find out which filter types Skia supports - Possibly add support for the remaining ones - Write a Skia FilterNode implementation - Find out how to get Skia DrawTargets and SourceSurfaces for CompositorOGL textures - If SkiaGL is not viable, implement accelerated filters in CompositorOGL by hand - Teach LayerManagerComposite to retain filtered results so that expensive filtering operations can be avoided if nothing has changed - Make nsDisplayFilter LAYER_ACTIVE if it has active children or if the filter is complex or animated, provided that the layer manager supports filters, so that filtering happens on the compositor
Flags: needinfo?(mstange)
Blocks: 422371
Blocks: 644368
Blocks: 830089
Blocks: 1272536
(In reply to Markus Stange [:mstange] from comment #2) > - Give filters their own nsDisplayItem type, e.g. nsDisplayFilter This has been done in bug 1295094. Everything else on the list in comment 2 still remains.
See Also: → 1480566
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 13 votes.
:bhood, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(bhood)
Severity: S3 → --
Type: defect → enhancement
Flags: needinfo?(bhood)

:ahale, can this bug be marked as a dupe of bug 1409486

Flags: needinfo?(ahale)
You need to log in before you can comment on or make changes to this bug.