Re: [dev-servo] Meeting notes (Q3)
> I wonder why Moz2D memory usage is a problem for Servo when we're shipping > Gecko (with Moz2D) on a 128MB phone. Not to distract from your valid points, but some of the context for this was about a much lower memory device. It's not clear it's even possible, but the question was whether we could ever fit in 32MB. There is significant interest internally and externally in low memory deployment. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes (Q3)
On Jul 7, 2014, at 6:39 PM, Robert O'Callahan 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
Re: [dev-servo] Meeting notes (Q3)
Sorry, I only just got to the workweek graphics meeting notes :-). Servo will need to support 2D canvas, and it requires something like Moz2D. So I think you're stuck with it or something like it. I'll talk to Bas etc about fixing some of the resource management issues your notes allude to in Moz2D. I think there are some things we can easily improve there. >- martin: Now for fixed pos elements, it looks like overflow is >calculated as if the display port is at 0,0. Does that seem correct? >- pcwalton: For fixed position elements, they get a separate layer, so >you can use 0,0 and it should be fine... maybe check via mail to the >mailing list on what to do there so we can ask roc and/or bz? I don't know >what the right thing to do with position:fixed is off the top of my head. >- pcwalton: I think you're going to always want to render all >position:fixed things and never cull them out. So, how do we know to >descend into elements that contained fixed position things. Maybe we should >just have a list of them on the root, since that's their containing block >anyway and always go into the unconditionally. You want to descend into >containing block that intersect with the viewport. In this case, it's the >root, so you'll always want to. > > I'm not really sure what the question is. In Gecko the overflow area for an element, er frame, is relative to the frame's own origin. position:fixed content doesn't move relative to the viewport but we do compute its overflow area based on the displayport bounds; this might be overkill but it is sometimes necessary, e.g. during async pinch-zoom-out. We mostly avoid culling involving position:fixed content, to make async scrolling work, but we did find one case is important: where a position:fixed element covers the entire viewport, we cull everything behind it. Another issue related to this is that getting 'opacity' and other container effects to work properly with position:fixed and other out-of-flow content is tricky. Consider e.g. . In Gecko we identify the out-of-flow content that is visible by traversing special child lists for the abs-pos, fixed-pos etc children of a containing block/viewport. But we can't paint them there and then because in this example the fixed-pos content must be rendered as part of the in-flow opacity:0.5 div (arbitrarily far away in the frame tree). So, after identifying the OOF content we need to draw, we set flags to ensure our frame-tree traversal descends down to the placeholder whether or not it's on-screen, and build display items for the OOF content in the context of the placeholder. I hope some of this is helpful... Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes (Q3)
On Tue, Jul 8, 2014 at 2:48 PM, Cameron Zwarich wrote: > We would also want to ensure that Harfbuzz and Moz2D aren’t somehow > creating duplicate copies of font data on all platforms. > They don't on Gecko, we've worked on that. I agree that image data and tile buffers are going to be very important. If you want to brainstom about getting to absurdly low memory targets like 32MB, I suggest talking to Nick Nethercote. This is where he lives. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes (Q3)
On Mon, Jul 7, 2014 at 8:03 PM, Robert O'Callahan wrote: > > If you want to brainstom about getting to absurdly low memory targets like > 32MB, I suggest talking to Nick Nethercote. This is where he lives. I've already been asked about whether SpiderMonkey could be made to work in that context. My response was "not likely". JS is a high-level, dynamically-typed, GC'd language, and SpiderMonkey is designed primarily for high performance, not low memory usage. If you implemented a new JS engine designed from the ground up for low memory usage, and you set your expectations really low, then you might be able to meet those expectations. Nick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes (Q3)
On 08/07/14 02:53, Jack Moffitt wrote: > this was about a much lower memory device. It's not clear it's even > possible, but the question was whether we could ever fit in 32MB. > There is significant interest internally and externally in low memory > deployment. How much, in volume, does 128MB of memory chips cost? And how much will they cost once Servo is ready for production deployment? What devices need to render full-fidelity web pages and can't afford that price? Gerv ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes (Q3)
> What devices need to render full-fidelity web pages and can't afford > that price? The current devices people were interested in targeting were 64MB and did not need full-fidelity web. They were actively pushing to reduce the HW requirement to 32MB. I cannot defend these requirements, but those were the ones we were investigating. jack. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
