Open Bug 869496 Opened 11 years ago Updated 1 year ago

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

Categories

(Core :: Graphics, enhancement)

enhancement

Tracking

()

People

(Reporter: jwatt, Unassigned)

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)
You need to log in before you can comment on or make changes to this bug.