Tracking bug for SkiaRenderer.
The idea is to merge Software and GL Renderer path and stop cc from accessing GL directly.
Tracking bug for SkiaRenderer.
The idea is to merge Software and GL Renderer path and stop cc from accessing GL directly.
See http://skbug.com/8505 for Skia optimizations to support SkiaRenderer
Next steps for skia renderer:
- Setup pixel test for tracking how complete the implementations are.
Current list of TODOs of not having implemented/tested in SkiaRenderer:
- sync_query
- FlippedFrameBuffer
- use_lcd_text + distance_field setup
- Render Pass:
- Fitlers
- Masks
- Background Filters
- Unsupported quad
- Copy Request
- DC Layers
- ImageFilter
Heads-up warning: Copy requests require direct access to GL because there are lower-level GPU operations being performed (e.g., viz::GLHelper::CreateYUVReadbackPipeline() and its suite of shader programs and texture mangling to do high quality scaling and image format conversion in the GPU). Even if there are Skia substitutes for these things, there may be major performance considerations here, especially when considering screen video capture. Have we investigated any of this yet?
FWIW, the tab capture impl in its current state is very difficult to evaluate, due to being spread-out across a number of modules and layers of abstraction (and multiple browser processes!). I'm working on moving it all into VIZ, into a much more compact/simple factoring for Mus/Mustache. At that point (ETA end-of-Q3), we will have much tighter integration with GLRenderer and SoftwareRenderer, and be in a better spot to see how things might work in terms of SkiaRenderer.
Comment 1 by weiliangc@chromium.org
, Sep 7 2016