Changes

Jump to: navigation, search

Platform/GFX/InternProjects

2,810 bytes removed, 19:33, 6 January 2012
Intern Projects
| {{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.<br><br>'''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
|-
| 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
|-
| Write a new scanline rasterizer for Cairo
| 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.
| ''TBD''
| jrmuizel
|-
| Speed up gradient rendering in Cairo
| 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.
| ''TBD''
| jrmuizel
|-
| GPU SVG filters
Confirm
336
edits

Navigation menu