On 11/11/14 1:02 PM, Robert O'Callahan wrote:
https://github.com/servo/servo/wiki/Workweek-rasterization
We talked about writing our own rasterizer, which makes sense because web
pages only render solid colored rectangles, image, and display text.
No. SVG, border-radius (rounded borders plus clipping to rounded shapes),
complex border styles, box-shadows and text-shadows are all commonly used,
and their performance matters. Plus you want to be able to rasterize these
precisely under arbitrary 2D affine transforms.
Firefox moved away from stateful APIs due to them being a bugfest,
according to the notes from gfx.
Not really. See http://robert.ocallahan.org/2011/09/graphics-api-design.html
for an explanation.
Skia is closer to Canvas-style than to the Moz2D style.
Is it? Last time I looked I thought the other way around. E.g. you have
SkCanvas::drawArc taking an SkPaint object with all the current drawing
state, although admittedly SkPaint is heavier-weight than the Moz2D
parameter objects. If you subject Skia to the analysis of my above blog
post, I think it lands on the stateless side. The only stacked state in
SkCanvas is the transform, the clip and the filter, which is much less than
cairo (where almost every possible drawing parameter is part of the context
state). Even Moz2D stores transform and clip in the DrawTarget (which is
about the minimum you need for it to make sense to pass a DrawTarget to an
arbitrary function saying "draw into this", which is essential).
Note that I was not in the above meeting, and I do not really follow the
reasoning that led to either abandoning Azure or writing our own rasterizer.
Patrick
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
