MozillaWiki

Platform/GFX/Firefox.next: Difference between revisions

Page Discussion

Platform/GFX/Firefox.next (view source)

Revision as of 13:05, 15 July 2011

5,831 bytes added ,  15 July 2011
→‎Detailed list of projects
No edit summary
 
(23 intermediate revisions by 7 users not shown)
Line 1: Line 1:
Lower fruit
= Detailed list of projects =
* Improve video performance - profiling and fixing problems
* better qcms ICCv4 support
** jrmuizel
* CSS 3D transforms
** bjacob


Medium sized
{| cellspacing="1" cellpadding="1" border="1" style="width: 100%; height: 113px;"
* border support in layers (9 part layers) - this should let us hardware accelerate border type effects better
|-
* cairo-gstate-backend for quartz and D2D
| '''Feature/Request'''
* accelerated layers on linux
| '''Contact'''
** bjacob
| '''Reason'''
* switch away from xlib to cairo-gl and 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?)
| '''GFX Owner'''
** bjacob
| '''Priority'''
* integrate cairo-gl for canvas on Mac and Linux (and maybe WinXP with ANGLE?)
|-
** bjacob
| Fennec Layers Acceleration
* themeing using GetThemeBitmap() - bug 561265
| Blizzard/Stuart
* Hardware accelerated plugin layers on windows
| For best possible performance on Fennec layers are required to be accelerated on Fennec.
* Layerize all remaining containers, namely SVG mask/clip-path/filters
| Jrmuizel & Bjacob
* Component alpha rendering using white and black source surfaces (if we don't get it into FF4)
| P1
* Multiple content processes feeding layer trees to a separate compositing process
|-
** bjacob (if other people join!)
| Electrolysis Accelerated Layers
* Animation of layer properties offloaded to the compositing process
| 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.
| Bas & cjones
| P1
|-
| Implement new CSS Font Spec
| jdaggett
| The new CCS font specification needs to be implemented.
| P1
|-
| WebGL antialiasing
| jgilbert
| Even though it's not a normative part of the spec, WebGL defaults to antialiasing, Chrome already supports it, and it's very visible for the end-user
| bjacob & jrmuizel
| P1
|-
| Layers 3D Transforms
| Roc
| CSS 3D transforms need to be supported by layers for good performance when we start supporting them.
| Mattwoodrow
| P1
|-
| Azure Cairo Backend
| Joe
| Azure requires a cairo backend so we can start experimenting with a Thebes wrapper around Azure, using Azure for gecko drawing.
| Bas & Roc
| P1
|-
| Fennec Gradient Performance
| Blizzard
| Common use cases slowed down by poorly performing gradients on ARM
| tbd
| P2
|-
| Accelerated Layers on X11
| ?
| Important feature that's still not default on X11. Matt's patches in bug 640082 are a large part of the work there, but there remains the Flash crash and probably some reftest failures.
| Bjacob & Mattwoodrow
| P2
|-
| WebGL 1.0 full conformance
| bjacob
| There's a good WebGL conformance test suite, and we already pass 98% of it. Make it 100%.
| bjacob
| P2
|-
| WebGL float textures extension
| bjacob
| This is a massively useful extension, Chrome supports it, and some cool WebGL apps require it.
| tbd (I think that Vlad had a patch)
| P2
|-
| Azure Thebes Wrapper
| Bas
| We should create a Thebes wrapper around Azure so we can get some early indications going on content rendering speed-up using Azure with the Direct2D backend.
| Bas & Roc
| P2
|-
| WebGL on Windows: default to OpenGL using D3D interop where possible
| bjacob
| Not using ANGLE can allow for a great performance boost, given good OpenGL drivers and D3D interop.
| bjacob & jrmuizel
| P2
|-
| 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.
| tbd
| P2
|-
| Fennec 2D HW Acceleration
| Stuart
| 2D Hardware Acceleration is important on mobile to further improve performance characteristics.
| tbd
| P2
|-
| 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
| P2
|-
| Border Drawing Performance
| Roc
| Border drawing is currently slower than it should be, this requires work.
| tbd
| P2
|-
| Accelerated Filters
| Roc
| Numerous filters could potentially be accelerated through layers. Leading to performance improvements.
| tbd {{bug|644368}} (partly)
| P2
|-
| Async Publishing of Video Frames
| Roc
| Needs motivation
| tbd {{bug|598868}}
| P2
|-
| 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
| P3
|-
| 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.
| Bas & Roc
| P3
|-
| 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.
| tbd
| ?
|}


'''Old list'''


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
 
= 18 month possibilities =
 
MoCo managers are trying to create a list of the work needing to be accomplished over the next 18 months.  The idea is to build a better picture of where we need to hire, train, etc. Following is the work we think we might want the GFX group to accomplish in the next 18 months.
 
# azure completed
## 2D and 3D parts
## option to use it for all drawing on desktop
## option to use it for all drawing on mobile
## cross process remoting
# webgl
## anti-aliasing
## ongoing spec compliance work (even for 1.0)
## webgl 2.0
## on going security and performance work
## E10S support
# Imagelib
## code debt reduction
## on going security and performance work
# telemetry/metrics
## better measurement of real-world performance
# text
## complete font spec implementation
## harfbuzz full script coverage
# OpenCL/WebCL
# GLES Layers
# Fully color corrected pipeline
# Hardware-accelerated SVG filters
# D3D11 Layers
 
This list is not a roadmap or a committed plan, its a rough outline of some of the big things we are likely to want to do.  In general I think we have the right skillsets, we just need more people with them.  The only exceptions are perhaps 6) and 9) - some more hard core shader/HLSL expertise might be helpful.
Bas
Confirmed users
138

edits

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