On Jul 7, 2014, at 6:39 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>> jack: We also had questions about replacing Azure with a thinner layer for >> disk/memory reasons. We talked to Bas about our options. He has some ideas >> already about what he wants to build as a new browser-focused graphics API >> from scratch. But that would be a multi-year, multi-person project for >> Gecko. Servo, on the other hand, only draws four things (boxes, lines, >> images, and text). So we could start building the API with support for just >> those four things, and add more as we go along. That would let us get rid >> of Azure and replace it with something more direct that just generates >> OpenGL calls. >> > > I don't know what's on Bas' mind, but it's not obvious to me how to design > a significantly better graphics API for browsers than Moz2D/Azure, which is > actually the result of going through just that process. If there is > something left on the table, let's evolve Moz2D towards it incrementally. I > don't want to add a 4th big-bang graphics API in Gecko. > > I wonder why Moz2D memory usage is a problem for Servo when we're shipping > Gecko (with Moz2D) on a 128MB phone. > > I think you need to look at the big picture rather than just what Servo > renders now. No point in stripping down an API just to add it all back > later. Independently of what Servo should actually use in ‘production’, I was interested in doing an experiment comparing CPU and GPU rasterization of Servo’s simple display list subset of 2D graphics (solid color rects, images, and text runs). This is easier to do with controlled implementations on a limited subset, especially if you just use CPU glyph rasterization from the platform's underlying graphics library. Past performance experiments I performed comparing the CPU and GPU backends of CoreGraphics in iOS WebKit were counterintuitive, in that CPU rasterization was usually better than GPU rasterization in terms of total page load times. I didn’t have time to do power usage comparisons, where I would hope the GPU backend would come out on top. Obviously, this is sensitive to CPU microarchitecture (Apple’s ARM CPUs generally have better SIMD performance than the competition), GPU architecture, and low-level GPU APIs (the console-style APIs that give more explicit control will fare better than generic OpenGL implementations). There was also discussion by Patrick and others that we could take advantage of our existing deferred mode display model in Servo to do some optimizations. There are still things like canvas that require an immediate mode API. I don’t know how big of an issue memory usage is. There are a few sources of memory to worry about: 1) Actual rendered tile buffers. These should be managed by Servo’s compositor, regardless of the backend. 2) Decoded image data. Hopefully Servo will be able to completely manage all of this data in the face of memory pressure. 3) Font data, both from the fonts themselves and any cached paths / bitmaps from glyph rendering. I know there have traditionally been a lot of problems with controlling this with 2D rasterization libraries, but maybe they’re all fixed? We would also want to ensure that Harfbuzz and Moz2D aren’t somehow creating duplicate copies of font data on all platforms. 4) Any intermediate resources used by the rasterizer. This is probably more of an issue for GPU rasterization, depending on the implementation. If you *really* care about reducing memory usage as much as possible, you would fall back to a more traditional model where you have a single double-buffered backing store for the entire screen rather than separate tiles that are composited, and you would just render as you pan (zooming would be much worse). Whether the latency of doing this is acceptable would depend on the target device and use case. Cameron _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
