Platform/GFX/Firefox.next
Jump to navigation
Jump to search
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