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

NEW
Unassigned

Status

()

Core
Graphics
4 years ago
3 months ago

People

(Reporter: jwatt, Unassigned)

Tracking

(Blocks: 8 bugs, {perf})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

4 years ago
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
(Reporter)

Updated

4 years ago
Blocks: 854024
(Reporter)

Updated

4 years ago
Blocks: 844664
(Reporter)

Updated

4 years ago
Blocks: 793507

Updated

4 years ago
Depends on: 869828
(Reporter)

Updated

4 years ago
Blocks: 703872
(Reporter)

Updated

4 years ago
Blocks: 699756
(Reporter)

Updated

4 years ago
Blocks: 749113
(Reporter)

Updated

4 years ago
Blocks: 609361
(Reporter)

Updated

4 years ago
Blocks: 601131
(Reporter)

Updated

4 years ago
Blocks: 483868
(Reporter)

Comment 1

3 years ago
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)
(Reporter)

Updated

3 years ago
Blocks: 422371
(Reporter)

Updated

3 years ago
Blocks: 644368
(Reporter)

Updated

3 years ago
Blocks: 830089
Blocks: 1141468
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.
You need to log in before you can comment on or make changes to this bug.