Platform/GFX/InternProjects: Difference between revisions

From MozillaWiki
< Platform‎ | GFX
Jump to navigation Jump to search
No edit summary
No edit summary
Line 51: Line 51:
| ''TBD''
| ''TBD''
| bjacob/joe
| bjacob/joe
|-
| Subpixel positioning of glyphs in the Cairo image surface
| 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.
| ''TBD''
| jrmuizel
|}
|}

Revision as of 17:59, 19 May 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
Implement the rest of ICCv4 in qcms Benoit Girard has a patch to significantly improve qcms's ICCv4 support, but even after his patches we don't fully support ICCv4. (CMYK support, for example, is entirely absent.) TBD BenWa/jrmuizel
Split imgIContainer into two interfaces 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. bug 503973 joe/bholley
Don't allocate memory for unused areas in animated GIF files when compositing 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 joe/bholley
Enable proper decode-on-draw on desktop 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. TBD joe/bholley
Do YCbCr/YUV->RGB conversion of JPEGs on the GPU 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.

Note: This is likely not a good project to start before we have a fully colour-managed pipeline or Emerald is complete.
TBD joe/jrmuizel/mattwoodrow
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
Subpixel positioning of glyphs in the Cairo image surface 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. TBD jrmuizel