Last Comment Bug 869496 - Accelerate CSS/SVG/custom filters (shaders, GLSL, GPU)
: Accelerate CSS/SVG/custom filters (shaders, GLSL, GPU)
Status: NEW
: perf
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: All All
-- normal with 10 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Milan Sreckovic [:milan]
Mentors:
https://wiki.mozilla.org/Gecko:Accele...
Depends on: 869828
Blocks: 422371 483868 644368 749113 793507 830089 844664 854024 1272536 601131 699756 703872 1141468
  Show dependency treegraph
 
Reported: 2013-05-07 09:01 PDT by Jonathan Watt [:jwatt]
Modified: 2016-05-27 14:33 PDT (History)
23 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description User image Jonathan Watt [:jwatt] 2013-05-07 09:01:49 PDT
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
Comment 1 User image Jonathan Watt [:jwatt] 2014-08-22 06:25:36 PDT
Markus, what still needs to happen here, and is there any sort of schedule?
Comment 2 User image Markus Stange [:mstange] 2014-08-27 07:19:42 PDT
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

Note You need to log in before you can comment on or make changes to this bug.