User:Jprosevear/GfxInternUpdate: Difference between revisions

(Created page with "= Intern Projects = Ideally, we'd like to have a set of intern projects from which prospective or new interns can pick and choose. These tasks should be relatively self-contain...")
 
 
(13 intermediate revisions by 2 users not shown)
Line 13: Line 13:
|-
|-
| Color Management
| Color Management
| Firefox uses the embedded qcms library for its color management.  There is support for some [http://www.color.org/ICC1v42_2006-05.pdf ICCv4] features, but there are several features missing including CMYK support and white/black points.  Additional work includes profiling of library performance and addition of small UI features such as displaying color profile information when viewing image info.
| Firefox uses the embedded qcms library for its color management.   
 
qcms supports some [http://www.color.org/ICC1v42_2006-05.pdf ICCv4] features, but there are several features missing including CMYK support and white/black points.  Additional work includes profiling of library performance and addition of small UI features such as displaying color profile information when viewing image info.
| ''TBD''
| ''TBD''
| BenWa/jrmuizel
| BenWa/jrmuizel
|-
|-
| Split imgIContainer into two interfaces
| ImageLib Memory Optimization
| imgIContainer should be split into two separate interfaces, one for decoders and libpr0n itself to use, and one for external users who just want to draw or get information about the current image.
| ImageLib caches and controls image information in Mozilla.
| {{bug|503973}}
 
| joe/bholley
Huge GIF files can be mostly empty space, but Mozilla currently allocates the full size of these images when compositing the frames together and drawing them to screen. Other browsers should be emulated so that only the parts of the frame that need to change are allocated, resulting in memory savings. This will be a good ImageLib introduction for the next phase.
|-
 
| Don't allocate memory for unused areas in animated GIF files when compositing
Currently Mozilla has the ability to throw away an image when it hasn't been drawn for a while, but we currently don't in order to eliminate flicker on the currently-displayed tab. We can probably get better heuristics for this, but doing so will also probably involve making asynchronous decoding more responsive, either by tweaking the way we asynchronously decode or the amount of data we asynchronously decode. This will greatly reduce the amount of memory we use on image-heavy pages.
| Huge GIF files can be mostly empty space, but we currently allocate the full size of these images when we're compositing the frames together and drawing them to screen. (Other browsers are smarter.) We should emulate other browsers, and only allocate the parts of the frame that need to change.
 
| {{bug|289763}}
| {{bug|289763}}
| joe/bholley
| joe/bholley
|-
|-
| Enable proper decode-on-draw on desktop
| WebGL Optional Features
| We have the ability to throw away an image when it hasn't been drawn for a while, but we currently don't to eliminate flicker on the currently-displayed tab. We can probably get better heuristics for this, but doing so will also probably involve making asynchronous decoding more responsive, either by tweaking the way we asynchronously decode or the amount of data we asynchronously decode. This will greatly reduce the amount of memory we use on image-heavy pages.
| WebGL makes OpenGL style 3D rendering available on the web, including the ability to create shaders. 
| ''TBD''
 
| joe/bholley
WebGL has an optional anti-aliasing hint which is not supported in Mozilla. We need to support this in order to improve rendering in WebGL.
 
Long running shaders can create DOS attacks.  Graphics drivers are rolling out support for the ARB_robustness extension (http://www.opengl.org/registry/specs/ARB/robustness.txt)  though, which mitigates this attack. The Mozilla code base needs to add support for these extensions.
| {{bug|656824}}, {{bug|615976}}
| bjacob/joe
|-
|-
| Do YCbCr/YUV->RGB conversion of JPEGs on the GPU
| WebGL Performance Improvements
| When we're using hardware-accelerated layers, we can reduce the amount of work we need to do on the CPU by decoding JPEGs to YUV only, uploading those channels to the GPU, and then converting the YUV to RGB in a shader.<br><br>'''Note''': This is likely not a good project to start before we have a fully colour-managed pipeline or Emerald is complete.
| WebGL makes OpenGL style 3D rendering available on the web.  Mozilla uses the ANGLE library on Windows to render OpenGL calls to Direct3D 9, but using it incurs a performance penalty. We should define what drivers are good enough, which will necessarily include Direct3D/OpenGL texture interoperability features, and measure how good performance is on these drivers with OpenGL vs using ANGLE.
| ''TBD''
 
| joe/jrmuizel/mattwoodrow
| {{bug|618898}}
|-
| Use ARB_robustness/ARB_robustness2 in our WebGL implementation where it's available
| Currently, even if a graphics driver implements and exports the ARB_robustness extension to make it less likely for shaders to DoS a computer, we don't use it. We should.
| {{bug|656824}}
| bjacob
|-
| Implement anti-aliasing in WebGL
| We don't currently honour the anti-aliasing hint in WebGL contexts, so our rendering looks inferior to Chrome's on the same demo on the same hardware. We should implement anti-aliasing.
| {{bug|615976}}
| bjacob
|-
| Use OpenGL for WebGL, instead of ANGLE, on "good enough" drivers
| ANGLE lets us support drivers with poor OpenGL implementations by rendering to Direct3D 9, but using it incurs a performance penalty. We should define what drivers are good enough, which will necessarily include Direct3D/OpenGL texture interop, and measure how good performance is on these drivers with OpenGL vs using ANGLE.
| ''TBD''
| bjacob/joe
| bjacob/joe
|-
|-
| Subpixel positioning of glyphs in the Cairo image surface
| Cairo Subpixel Glyph Positioning
| Currently we snap glyphs to pixel boundaries in the image surface, which is good for performance because we can rasterize glyphs only once (in glyph space) and then re-use those rasterized glyphs as a glyph cache. We should change this to rasterize glyphs at (for example) third-pixel boundaries, and then snap our glyph positions to these third-pixel boundaries.
| Cairo is a 2D rendering library that is currently used for most drawing operations in Mozilla.  Currently Mozilla snaps glyphs to pixel boundaries in the cairo image surface, which is good for performance because we can rasterize glyphs only once (in glyph space) and then re-use those rasterized glyphs as a glyph cache. We should change this to rasterize glyphs at (for example) third-pixel boundaries, and then snap our glyph positions to these third-pixel boundaries.
| ''TBD''
| ''TBD''
| jrmuizel
| jrmuizel
|-
|-
| Write a new scanline rasterizer for Cairo
| Cairo Scanline Rasterizer
| The current approach is fast and high quality, but complicated, and has problems with clipping invariance. We can probably serve our needs better with something simpler, lower quality, and hopefully very fast, like skia.
| Cairo is a 2D rendering library that is currently used for most drawing operations in Mozilla.  The current scanline rasterizer in cairo is fast and high quality, but complicated, and has problems with clipping invariance. We can probably serve our needs better with something simpler, lower quality, and hopefully very fast, like skia.
| ''TBD''
| ''TBD''
| jrmuizel
| jrmuizel
|-
|-
| Speed up gradient rendering in Cairo
| Cairo Gradient Rendering Performance
| Rendering gradients is slower than it should be, especially on ARM. The current performance needs to be measured and the current rendering methods worked out, then it needs to be sped up significantly. This can be through better rendering methods, parallelization (e.g. SIMD instruction use), or other methods.
| Cairo is a 2D rendering library that is currently used for most drawing operations in Mozilla and gradients are increasingly important for use in CSS.  However rendering of gradients is very slow in Cairo currently, especially on ARM. Current performance needs to be measured and profiled, current rendering methods reviewed and finally improved. A variety of options such altering rendering methods or parallelization (e.g. SIMD instruction use) can be used to achieve the performance gains.
| ''TBD''
| ''TBD''
| jrmuizel
| jrmuizel
|-
|-
| GPU SVG filters
| SVG Filters on GPU
| SVG filters are currently implemented through software rendering on the CPU, even when Firefox is using hardware for its general 2D rendering (i.e., when using Direct2D). These should be reimplemented using HLSL shaders to avoid readback. The biggest challenges here will be allowing arbitrary chaining of filters, as well as making it possible to avoid reimplementation once we need to support OpenGL shaders too.
| Mozilla currently supports SVG filters, however these are currently implemented using software rendering on the CPU.  This is the case even when hardware acceleration is used for general 2D rendering (i.e., Direct2D). SVG filter support should be extended for hardware acceleration using HLSL shaders to avoid readbacks. The biggest challenges here will be allowing arbitrary chaining of filters, as well as making it possible to avoid reimplementation once we need to support OpenGL shaders too.  
| ''TBD''
| ''TBD''
| roc
| roc
 
|-
| Efficient Clipping on GPU
| Mozilla renders a page as a series of layers that are composited together, using the GPU when possible.  Clipping and opacity are properties on individual layers.  The current GPU layer clipping code requires the clip to be an axis-aligned rectangle, and in other cases we are allocating an intermediate surface and rendering to that (transformations), or handling the render in software (SVG). We should be able to handle this using the stencil buffer or similar.
| ''TBD''
| mattwoodrow/roc
|-
| Store Images as Textures
| Mozilla renders a page as a series of layers that are composited together, using the GPU when possible.  When Mozilla separates an image into a dedicated layer we have two copies of the data, one in system memory (owned by imglib) and one as a texture. We can teach imglib about this second copy and free the system memory one in some cases to save memory usage. This is particularly useful for mobile (Android) where image scaling is much cheaper on the GPU, but the memory cost of two copies will hurt.
| {{bug|650988}} for mobile's usage of this.
| mattwoodrow/joe/roc
|}
|}

Latest revision as of 12:22, 1 June 2011

Intern Projects

Ideally, we'd like to have a set of intern projects from which prospective or new interns can pick and choose. These tasks should be relatively self-contained, challenging but not impossible, and well-defined.

Please link to bugs where appropriate.

Name Description Bugs Mentor
Color Management Firefox uses the embedded qcms library for its color management.

qcms supports some ICCv4 features, but there are several features missing including CMYK support and white/black points. Additional work includes profiling of library performance and addition of small UI features such as displaying color profile information when viewing image info.

TBD BenWa/jrmuizel
ImageLib Memory Optimization ImageLib caches and controls image information in Mozilla.

Huge GIF files can be mostly empty space, but Mozilla currently allocates the full size of these images when compositing the frames together and drawing them to screen. Other browsers should be emulated so that only the parts of the frame that need to change are allocated, resulting in memory savings. This will be a good ImageLib introduction for the next phase.

Currently Mozilla has the ability to throw away an image when it hasn't been drawn for a while, but we currently don't in order to eliminate flicker on the currently-displayed tab. We can probably get better heuristics for this, but doing so will also probably involve making asynchronous decoding more responsive, either by tweaking the way we asynchronously decode or the amount of data we asynchronously decode. This will greatly reduce the amount of memory we use on image-heavy pages.

bug 289763 joe/bholley
WebGL Optional Features WebGL makes OpenGL style 3D rendering available on the web, including the ability to create shaders.

WebGL has an optional anti-aliasing hint which is not supported in Mozilla. We need to support this in order to improve rendering in WebGL.

Long running shaders can create DOS attacks. Graphics drivers are rolling out support for the ARB_robustness extension (http://www.opengl.org/registry/specs/ARB/robustness.txt) though, which mitigates this attack. The Mozilla code base needs to add support for these extensions.

bug 656824, bug 615976 bjacob/joe
WebGL Performance Improvements WebGL makes OpenGL style 3D rendering available on the web. Mozilla uses the ANGLE library on Windows to render OpenGL calls to Direct3D 9, but using it incurs a performance penalty. We should define what drivers are good enough, which will necessarily include Direct3D/OpenGL texture interoperability features, and measure how good performance is on these drivers with OpenGL vs using ANGLE. bug 618898 bjacob/joe
Cairo Subpixel Glyph Positioning Cairo is a 2D rendering library that is currently used for most drawing operations in Mozilla. Currently Mozilla snaps glyphs to pixel boundaries in the cairo image surface, which is good for performance because we can rasterize glyphs only once (in glyph space) and then re-use those rasterized glyphs as a glyph cache. We should change this to rasterize glyphs at (for example) third-pixel boundaries, and then snap our glyph positions to these third-pixel boundaries. TBD jrmuizel
Cairo Scanline Rasterizer Cairo is a 2D rendering library that is currently used for most drawing operations in Mozilla. The current scanline rasterizer in cairo is fast and high quality, but complicated, and has problems with clipping invariance. We can probably serve our needs better with something simpler, lower quality, and hopefully very fast, like skia. TBD jrmuizel
Cairo Gradient Rendering Performance Cairo is a 2D rendering library that is currently used for most drawing operations in Mozilla and gradients are increasingly important for use in CSS. However rendering of gradients is very slow in Cairo currently, especially on ARM. Current performance needs to be measured and profiled, current rendering methods reviewed and finally improved. A variety of options such altering rendering methods or parallelization (e.g. SIMD instruction use) can be used to achieve the performance gains. TBD jrmuizel
SVG Filters on GPU Mozilla currently supports SVG filters, however these are currently implemented using software rendering on the CPU. This is the case even when hardware acceleration is used for general 2D rendering (i.e., Direct2D). SVG filter support should be extended for hardware acceleration using HLSL shaders to avoid readbacks. The biggest challenges here will be allowing arbitrary chaining of filters, as well as making it possible to avoid reimplementation once we need to support OpenGL shaders too. TBD roc
Efficient Clipping on GPU Mozilla renders a page as a series of layers that are composited together, using the GPU when possible. Clipping and opacity are properties on individual layers. The current GPU layer clipping code requires the clip to be an axis-aligned rectangle, and in other cases we are allocating an intermediate surface and rendering to that (transformations), or handling the render in software (SVG). We should be able to handle this using the stencil buffer or similar. TBD mattwoodrow/roc
Store Images as Textures Mozilla renders a page as a series of layers that are composited together, using the GPU when possible. When Mozilla separates an image into a dedicated layer we have two copies of the data, one in system memory (owned by imglib) and one as a texture. We can teach imglib about this second copy and free the system memory one in some cases to save memory usage. This is particularly useful for mobile (Android) where image scaling is much cheaper on the GPU, but the memory cost of two copies will hurt. bug 650988 for mobile's usage of this. mattwoodrow/joe/roc