Platform/GFX/Firefox.next: Difference between revisions

From MozillaWiki
< Platform‎ | GFX
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
Lower fruit
{| cellspacing="1" cellpadding="1" border="1" style="width: 100%; height: 113px;"
* Improve video performance - profiling and fixing problems
|-
* better qcms ICCv4 support
| '''Feature/Request'''
** jrmuizel
| '''Contact'''
* CSS 3D transforms
| '''Reason'''
** bjacob
| '''Target'''
** joe
| '''GFX Owner'''
| '''Estimated Work'''
|-
| Fennec Layers Acceleration
| Blizzard/Stuart
| For best possible performance on Fennec layers are required to be accelerated on Fennec.
| ?
| tbd
| ?
|-
| Electrolysis Accelerated Layers
| Blizzard
| In order not to regress performance in electrolysis builds all types of accelerated layers need to be able to operate in conjunction with electrolysis.
| e10s (Fx7?)
| tbd
| ?
|-
| Fennec Gradient Performance
| Blizzard
| Common use cases slowed down by poorly performing gradients on ARM
| ?
| tbd
| ?
|-
| Common Benchmark Perf Improvements
| Blizzard
| It's important to perform well on commonly quoted benchmarks. Even when they are not necessarily representative of common browser usage they strongly influence impression of browser performance.
| Continuous
| tbd
| ?
|-
| Cross Process WebGL
| Stuart(Fennec) Blizzard(Desktop)
| In the future we will need a way to render WebGL fast, without readback from a content process and render it into the composition process, to avoid the performance impact from readback to software.
| Fennec Unknown(ASAP?), Desktop e10s (Fx7)
| tbd
| ?
|-
| Fennec 2D HW Acceleration
| Stuart(Fennec)
| 2D Hardware Acceleration is important on mobile to further improve performance characteristics.
| ?
| tbd
| ?
|-
| '''NGFX'''
| Internal
| Replacing cairo with a more modern, flexible graphics library is deemed needed for a variety of performance & long term multiprocess needs
| ? (Fx8?)
| tbd
| ?
|-
| NPAPI Async Drawing Extension
| Bas
| With the release of IE9 and Flash 10.2 IE has created an easier method for windowless plugin drawing. For performance and other reasons (such as the current elaborate background copying/alpha recovery scheme) a more efficient drawing model for windowless plugins is required.
| ?
| tbd
| ?
|-
| Container Layer Masking/Clipping
| Roc
| Make container layers support clip-path, filter and mask APIs, including clipping to rounded-rectangles, so we can avoid dropping down to fallback, avoiding performance hits.
| ?
| tbd
| ?
|-
| Border Drawing Performance
| Roc
| Border drawing is currently slower than it should be, this requires work.
| ?
| tbd
| ?
|-
| Layers 3D Transforms
| Roc
| CSS 3D transforms need to be supported by layers for good performance when we start supporting them.
| ?
| tbd
| ?
|-
| Accelerated Filters
| Roc
| Numerous filters could potentially be accelerated through layers. Leading to performance improvements.
| ?
| tbd
| ?
|-
| Layers Animation API
| Roc
| By making animations implicitly supported inside layers, those animations can be executed asynchronously in the composition process, allowing for smoother animation.
| ?
| tbd
| ?
|-
| Async Publishing of Video Frames
| Roc
| Needs motivation
| ?
| tbd
| ?
|}


Medium sized
'''Old list'''
* Define new 2D API and prototype it on D2D
* Implement cairo-surface-backend and Quartz backends for new 2D API
* Implement GL backend for new 2D API
* border support in layers (9 part layers) - this should let us hardware accelerate border type effects better
** joe
** ''roc: I'm not sure what the goal is here. We need to rework border drawing on the layout side, but I don't think layers and borders are related.''
* accelerated layers on linux
** bjacob
** joe
* switch away from xlib to cairo-gl and/or image backends on linux (note: the size of this item depends a lot on the current status of cairo-gl: how much do we need to fix it ourselves?)
** bjacob
** joe - but we should probably not put more than one person on this
* integrate cairo-gl (maybe just for canvas?) on Mac and Linux (and maybe WinXP with ANGLE?)
** bjacob
** joe
* themeing using GetThemeBitmap() - bug 561265
* Hardware accelerated plugin layers on windows
* Layerize all remaining containers, namely SVG mask/clip-path/filters
* Animation of layer properties offloaded to the compositing process
* any WebGL work that would not make it into 4.0 (optimizations, still-in-flux parts of the spec such as color correction, lost-context events, using ARB_robustness...?)
** bjacob


Things that would be nice
Lower fruit
* software rasterizer tuning - we could probably use a quick and dirty rasterizer for mobile where the pixels are small
 
*Improve video performance - profiling and fixing problems
*better qcms ICCv4 support
**jrmuizel
*CSS 3D transforms
**bjacob
**joe
 
Medium sized
 
*Define new 2D API and prototype it on D2D
*Implement cairo-surface-backend and Quartz backends for new 2D API
*Implement GL backend for new 2D API
*border support in layers (9 part layers) - this should let us hardware accelerate border type effects better
**joe
**''roc: I'm not sure what the goal is here. We need to rework border drawing on the layout side, but I don't think layers and borders are related.''
*accelerated layers on linux
**bjacob
**joe
*switch away from xlib to cairo-gl and/or image backends on linux (note: the size of this item depends a lot on the current status of cairo-gl: how much do we need to fix it ourselves?)
**bjacob
**joe - but we should probably not put more than one person on this
*integrate cairo-gl (maybe just for canvas?) on Mac and Linux (and maybe WinXP with ANGLE?)
**bjacob
**joe
*themeing using GetThemeBitmap() - bug 561265
*Hardware accelerated plugin layers on windows
*Layerize all remaining containers, namely SVG mask/clip-path/filters
*Animation of layer properties offloaded to the compositing process
*any WebGL work that would not make it into 4.0 (optimizations, still-in-flux parts of the spec such as color correction, lost-context events, using ARB_robustness...?)
**bjacob
 
Things that would be nice  
 
*software rasterizer tuning - we could probably use a quick and dirty rasterizer for mobile where the pixels are small

Revision as of 21:26, 27 March 2011

Feature/Request Contact Reason Target GFX Owner Estimated Work
Fennec Layers Acceleration Blizzard/Stuart For best possible performance on Fennec layers are required to be accelerated on Fennec. ? tbd ?
Electrolysis Accelerated Layers Blizzard In order not to regress performance in electrolysis builds all types of accelerated layers need to be able to operate in conjunction with electrolysis. e10s (Fx7?) tbd ?
Fennec Gradient Performance Blizzard Common use cases slowed down by poorly performing gradients on ARM ? tbd ?
Common Benchmark Perf Improvements Blizzard It's important to perform well on commonly quoted benchmarks. Even when they are not necessarily representative of common browser usage they strongly influence impression of browser performance. Continuous tbd ?
Cross Process WebGL Stuart(Fennec) Blizzard(Desktop) In the future we will need a way to render WebGL fast, without readback from a content process and render it into the composition process, to avoid the performance impact from readback to software. Fennec Unknown(ASAP?), Desktop e10s (Fx7) tbd ?
Fennec 2D HW Acceleration Stuart(Fennec) 2D Hardware Acceleration is important on mobile to further improve performance characteristics. ? tbd ?
NGFX Internal Replacing cairo with a more modern, flexible graphics library is deemed needed for a variety of performance & long term multiprocess needs ? (Fx8?) tbd ?
NPAPI Async Drawing Extension Bas With the release of IE9 and Flash 10.2 IE has created an easier method for windowless plugin drawing. For performance and other reasons (such as the current elaborate background copying/alpha recovery scheme) a more efficient drawing model for windowless plugins is required. ? tbd ?
Container Layer Masking/Clipping Roc Make container layers support clip-path, filter and mask APIs, including clipping to rounded-rectangles, so we can avoid dropping down to fallback, avoiding performance hits. ? tbd ?
Border Drawing Performance Roc Border drawing is currently slower than it should be, this requires work. ? tbd ?
Layers 3D Transforms Roc CSS 3D transforms need to be supported by layers for good performance when we start supporting them. ? tbd ?
Accelerated Filters Roc Numerous filters could potentially be accelerated through layers. Leading to performance improvements. ? tbd ?
Layers Animation API Roc By making animations implicitly supported inside layers, those animations can be executed asynchronously in the composition process, allowing for smoother animation. ? tbd ?
Async Publishing of Video Frames Roc Needs motivation ? tbd ?

Old list

Lower fruit

  • Improve video performance - profiling and fixing problems
  • better qcms ICCv4 support
    • jrmuizel
  • CSS 3D transforms
    • bjacob
    • joe

Medium sized

  • Define new 2D API and prototype it on D2D
  • Implement cairo-surface-backend and Quartz backends for new 2D API
  • Implement GL backend for new 2D API
  • border support in layers (9 part layers) - this should let us hardware accelerate border type effects better
    • joe
    • roc: I'm not sure what the goal is here. We need to rework border drawing on the layout side, but I don't think layers and borders are related.
  • accelerated layers on linux
    • bjacob
    • joe
  • switch away from xlib to cairo-gl and/or image backends on linux (note: the size of this item depends a lot on the current status of cairo-gl: how much do we need to fix it ourselves?)
    • bjacob
    • joe - but we should probably not put more than one person on this
  • integrate cairo-gl (maybe just for canvas?) on Mac and Linux (and maybe WinXP with ANGLE?)
    • bjacob
    • joe
  • themeing using GetThemeBitmap() - bug 561265
  • Hardware accelerated plugin layers on windows
  • Layerize all remaining containers, namely SVG mask/clip-path/filters
  • Animation of layer properties offloaded to the compositing process
  • any WebGL work that would not make it into 4.0 (optimizations, still-in-flux parts of the spec such as color correction, lost-context events, using ARB_robustness...?)
    • bjacob

Things that would be nice

  • software rasterizer tuning - we could probably use a quick and dirty rasterizer for mobile where the pixels are small
Retrieved from "https://wiki.allizom.org/index.php?title=Platform/GFX/Firefox.next&oldid=294151"