MozillaWiki

Platform/GFX/Firefox.next: Difference between revisions

Page Discussion

Platform/GFX/Firefox.next (view source)

Revision as of 21:26, 27 March 2011

2,946 bytes added ,  27 March 2011
no edit summary
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
Bas
Confirmed users
138

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/294151"