Re: [dev-servo] State of Servo

On 7/11/12 10:09 AM, Ian Melven wrote: Also, in general, i'm pretty curious about Servo's process model and its security architecture, maybe that's best discussed in a new thread though (I really need to take some time to understand Rust better as well). My particular interest is in how Servo

Re: [dev-servo] How to deal when layout lags behind DOM updates

On 7/12/12 6:45 PM, Boris Zbarsky wrote: I was talking to BenWa today, and he asked how the RCU world handles this situation: 1) DOM update starts at time t=0 2) DOM update finishes at time t=1, schedules 4ms setTimeout 3) Layout starts at time t=1 4) Timer fires at t=5, updates DOM 5) DOM

Re: [dev-servo] Handling adoptNode

On 10/19/12 1:55 PM, Boris Zbarsky wrote: Do we have a plan for adoptNode? If we're allocating nodes out of the JS heap, presumably we'll need to brain-transplant the JSObject and then copy over the implementation into the new compartment... and make sure we update any pointers to the implementa

[dev-servo] Submodule split

Just FYI, I've split out GFX and all its dependencies (image, resource, text, most of util) into the servo-gfx crate as a submodule. This means that if you're just modifying layout you can avoid rebuilding some ~5000 lines of code of the graphics module. The resource crate and util should furt

Re: [dev-servo] Submodule split

On 11/11/12 8:25 PM, Brian Burg wrote: In what sense are any of these things (outside of utility-like data structures) reusable? Or, is it possible to swap out one implementation for another? Is this just a workaround for lacking incremental compilation? Do we want to encourage modularity at the

Re: [dev-servo] Submodule split

On 11/12/12 8:04 AM, Brian Burg wrote: In the case of rust bindings to other APIs (which is what most of the submodules are), separate repositories and crates make sense. For parts of servo like gfx, css, dom, and layout, I think it makes sense to put them in separate crates but in the same repo

Re: [dev-servo] More planning

On 2/13/13 7:16 PM, Boris Zbarsky wrote: On 2/13/13 9:47 PM, Brian Anderson wrote: During a lunch discussion today we decided that we have three areas that we care most about this year: layout, crow, and dom bindings. We still need to make basic measurements of round-trip times through our DOM

Re: [dev-servo] More planning

On 2/13/13 7:23 PM, Robert O'Callahan wrote: I think it's critical to examine the performance of Servo DOM+layout at its most vulnerable, which I think is when JS is synchronously pounding on it. A couple of microbenchmarks spring to mind: 1) DOM bindings performance for simple DOM operations, e.

Re: [dev-servo] More planning

On 2/13/13 7:25 PM, Robert O'Callahan wrote: I also think that sandboxing the engine is not interesting. Assuming you're talking about OS-level process sandboxing, there's no risk there; we know browser engines can be sandboxed that way. I don't plan to spend time on the OS-specific parts of th

Re: [dev-servo] More planning

On 2/13/13 9:43 PM, Robert O'Callahan wrote: (Of course a big sandbox around the entire browser, or independent browsing contexts, could still be useful as a second line of defense to prevent the system from being persistently corrupted in case of a Rust exploit.) That's exactly the purpose. Mo

Re: [dev-servo] More planning

On 2/13/13 10:06 PM, Boris Zbarsky wrote: That sounds like it should be fast enough, yes. We should verify that it actually is in practice. Which to me suggests that the scheduler rewrite is a higher priority than, say, floats. At least if they're both gated on brson. ;) Do we have any ETA o

Re: [dev-servo] More planning

On 2/13/13 11:11 PM, Boris Zbarsky wrote: Only sets on clean nodes are slow, right? Once you've set something, you just keep writing to the already-allocated bit. Right. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.m

[dev-servo] New DOM implementation

I have started work a new DOM implementation in the "dom" branch. It is currently building except for an internal compiler error, the fix for which is currently being upstreamed to Rust. This new DOM implementation is based on structs instead of enums. The base type is `AbstractNode`, which is

Re: [dev-servo] New DOM implementation

On 2/17/13 3:16 AM, smaug wrote: Curious, how does GC manage nodes? Do we explicitly trace even those nodes which don't have js wrappers or do we just use GC for everything in Rust? All the nodes in Servo have JS wrappers at the moment, and their lifetimes are managed by the JS garbage collect

Re: [dev-servo] New DOM implementation

from being stored in untraced objects at all (perhaps by making them noncopyable and using the region system in a similar way to layout above). Will need to think about this a bit more. Patrick Robert O'Callahan wrote: >On Mon, Feb 18, 2013 at 7:27 AM, Patrick Walton >wrote: > &g

[dev-servo] Removing Cairo from the tree

Cairo and Pixman are hard to build on some platforms like the Mac, and I think Skia-GL, CoreGraphics, Direct2D is where we want to focus our efforts in the future. To that end I'd like to remove Cairo from the Servo tree. It'll still be possible to use Cairo through Azure. It'll just have to

Re: [dev-servo] Removing Cairo from the tree

On 3/13/13 11:31 AM, Boris Zbarsky wrote: On 3/13/13 2:09 PM, Patrick Walton wrote: It'll still be possible to use Cairo through Azure. It'll just have to be preinstalled on the system--we won't build it ourselves. I think this is probably OK for Linux systems including Tiz

Re: [dev-servo] Codegen WIP

On 3/13/13 2:06 PM, Josh Matthews wrote: I just pushed the result of my work to the master branch. The bindings for ClientRect and ClientRectList should be generated from their respective webIDL files as part of the build now, and running test/test_bindings.html should show the (totally faked) re

Re: [dev-servo] First synchronous hammering performance numbers

So I guess the problem is that setAttribute() is slow? Josh Matthews wrote: >On 05/27/2013 03:45 PM, Josh Matthews wrote: >> On 05/27/2013 02:25 PM, Josh Matthews wrote: >>> The following script (test_hammer_layout.html) can now run in Servo, >so >>> I've finally been able to begin obtaining bas

[dev-servo] Handling the case where a child becomes non-inline

Hi everyone, We're starting on incremental layout, in order to improve performance of the layout benchmarks we are most focused on (`test_hammer_layout` and `test_slam_layout`). It was also felt, based on past experience, that having incremental layout from the start is important to get in ear

Re: [dev-servo] Handling the case where a child becomes non-inline

On 6/5/13 8:30 AM, Boris Zbarsky wrote: On 6/4/13 9:47 PM, Patrick Walton wrote: We're trying to figure out what to do when an inline RenderBox of an inline flow becomes non-inline. This is a vexing issue, as it violates the invariant that a flow's descendants and the flow itself ar

[dev-servo] Minutes of the discussion regarding strings

Topics covered: Interning, mutability, cost of creating string objects, encoding UTF-8 versus UTF-16. https://github.com/mozilla/servo/wiki/Strings Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-s

Re: [dev-servo] Minutes of the discussion regarding strings

On 6/7/13 6:43 AM, Benjamin Smedberg wrote: On 6/5/2013 8:42 PM, Patrick Walton wrote: Topics covered: Interning, mutability, cost of creating string objects, encoding UTF-8 versus UTF-16. https://github.com/mozilla/servo/wiki/Strings I would love to have been invited to this meeting. Was it

Re: [dev-servo] Where do styles live, and how to make it work with CSS fragmentation stuff

On 6/13/13 5:45 PM, Joel Feenstra wrote: What about an enum of the various style lookup strategies with inlining for all of them. Rustc/LLVM may need to be able to inline 2 levels of function calls (to call the enum impl and then the value impl), and I know it isn't great at inlining currently.

Re: [dev-servo] Where do styles live, and how to make it work with CSS fragmentation stuff

On 6/13/13 5:48 PM, Joel Feenstra wrote: I thought inline attributes had to be added to things. Maybe that was a while ago. They do to get cross-crate inlining to work. That's by design, so that you can replace the bodies of non-inlined functions without having to recompile all downstream cr

Re: [dev-servo] Unanswered questions from a Q&A about Servo

Here are my attempts at answers. On 7/12/13 10:51 AM, Josh Matthews wrote: * Are there viability criteria? How much better (performance-wise) than other engines does Servo have to be considered worth continued investment? No idea. There are both security and performance wins, so both must be

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 11:04 AM, Benjamin Smedberg wrote: I'd like to understand what the parallelism targets are... if DOM and layout are not parallelized with a single DOM tree but we can run multiple of these tasks at once (so that tabs are isolated from eachother) is that good enough for a v1 product? Is

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 12:18 PM, Josh Matthews wrote: When you say "very much", I get worried. All codegen'ed DOM code uses @ pointers Does it need to use @ pointers? That seems unfortunate. and I don't understand what you mean by "can't have strong references to DOM nodes"; consider events we eventually

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 12:43 PM, Josh Matthews wrote: Yes, this is the bed we have made for ourselves in Servo at this point. Can we just have the JS trace hook for a DOM node recursively search through children for wrappers, even those that don't have wrappers? To illustrate, suppose we have this DOM:

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 1:27 PM, Boris Zbarsky wrote: What keeps the "X" that is a child of "2" alive? Interesting question. I had assumed that X's were kept alive by their parents. After all, JS will not try to free things that it doesn't know about (and presumably JS doesn't know about wrapperless nodes

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 1:40 PM, Jack Moffitt wrote: I can write an example of a script that would produce such a situation, if desired. Yes, please. I would love to have a concrete example. So I think there are basically three options: 1. Use the JS GC for everything; eat the cost of eagerly creating al

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 4:45 PM, Patrick Walton wrote: 1. Use the JS GC for everything; eat the cost of eagerly creating all wrappers. As Boris mentioned, maybe this isn't so bad. I would assume this is what Oilpan is doing in Blink. After talking to Terrence from the JS team, apparently with a mon

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 5:38 PM, Robert O'Callahan wrote: What would the developer experience be like with this approach? I mean, what kind of code would developers have to write to declare classes managed by JS and to declare references to such objects? I suspect it would be something like: #[deriving

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 5:48 PM, Robert O'Callahan wrote: Does Option> compile down to a single machine word with no overhead for dereferencing? The Rust compiler now implements optimizations to compile Option of a pointer down to a nullable pointer (although I would have to verify that it indeed works in

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 7:11 PM, Boris Zbarsky wrote: Hmm. 18 64-bit words is enough for a basic element, I'd think, though with the copy/on-write setup we would need to measure carefully. Subclasses might need to heap-allocate some of their members, though, which is a bit of a pain. Right; unique pointers

Re: [dev-servo] Unanswered questions from a Q&A about Servo

On 7/12/13 7:09 PM, Boris Zbarsky wrote: On 7/12/13 7:45 PM, Patrick Walton wrote: 2. Use the JS GC for wrapped objects and reference counting for non-wrapped objects. This assumes there are no cycles between them, which I believe to be the case (though could be wrong) If we can have both

Re: [dev-servo] Meeting notes - further discussion of selected topics from "Unanswered questions" thread

On 7/15/13 3:58 PM, Robert O'Callahan wrote: For compositing with IFRAMEs, you might want to consider what we do for multi-process compositing in Gecko. It's somewhat obvious but it seems like it works well. Each process publishes a layer tree to the compositor. A layer tree can contain RefLayers

Re: [dev-servo] Safe abstractions for unique handles

On 7/15/13 4:32 PM, Robert O'Callahan wrote: A minor random thought related to that design: Using integer IDs, as Gecko does, raises the possibility of a bug, possibly even a security bug, where a rogue IFRAME is able to render itself at the wrong place in the tree. In Gecko, preventing a compro

[dev-servo] Plans for parallel constraint solving in layout

Hi everyone, Eric Atkinson and I whiteboarded some ideas for ensuring data race freedom and memory safety while performing parallel constraint solving in layout. Here are some random notes from that discussion as well as previous discussions we've had: * Parallel constraint solving is about

Re: [dev-servo] Plans for parallel constraint solving in layout

We just had another discussion with several outcomes: # Floats Height assignment is currently an in-order traversal in Servo, to cope with floats. However, this could be turned into a bottom-up traversal. The trick is to treat all DOM subtrees that contain floats (and no `clear: both`) as sin

Re: [dev-servo] Inline DOM storage progress report

On 7/23/13 7:08 PM, Boris Zbarsky wrote: On 7/23/13 6:34 PM, Josh Matthews wrote: Accordingly, there are now branches of servo, rust-mozjs, and mozjs (all named 'inline') that contain my work to date on storing DOM objects inline in their JS wrappers' fixed slots. There are some rooting problems

Re: [dev-servo] Inline DOM storage progress report

On 7/25/13 8:30 AM, Boris Zbarsky wrote: On 7/24/13 12:16 PM, Josh Matthews wrote: All DOM objects are represented with |JSManaged whatever|. When you want to access a property owner_document of Whatever, you use |do whatever.with_imm |whatever| { whatever.owner_document }|, and |do whatever.wit

Re: [dev-servo] cssparser meeting notes

On 8/2/13 1:39 PM, Boris Zbarsky wrote: 1) How fast is a Reader in practice? Gecko used to use an input stream for the parser and switched to a flat character buffer because it was significantly faster, even if you ignore the cost of Read() calls: the logic getting the next char became much sim

Re: [dev-servo] cssparser meeting notes

On 8/2/13 1:46 PM, Brendan Eich wrote: It's hard to beat raw buffer access. We shouldn't try to be too smart here. Do we have *safe* raw buffer access options on the boards? (E.g., XDR inline from the old days: a way to ask for contiguous, inline-function-deserializable memory?) I'm not sure wh

Re: [dev-servo] cssparser meeting notes

On 8/2/13 1:47 PM, Jack Moffitt wrote: When you say they are very slow, do you mean any use of the Reader trait, or just the FILE and other implementations? Any use of the Reader trait. Patrick ___ dev-servo mailing list dev-servo@lists.mozilla.org

Re: [dev-servo] cssparser meeting notes

On 8/2/13 1:50 PM, Boris Zbarsky wrote: On 8/2/13 4:47 PM, Jack Moffitt wrote: Using a Reader doesn't imply that we're not reading from a character buffer. The question is whether the compiler can devirtualize at the callsite so it can optimize around the read call, or possibly even inline it.

Re: [dev-servo] 0.1 release criteria

On 8/2/13 12:23 PM, Jack Moffitt wrote: I've created a page with a straw-man proposal of these criteria, and any input is welcome. Should we have more things? Or less? https://github.com/mozilla/servo/wiki/Version-0.1 You missed the all-important code name. Added. Patrick ___

Re: [dev-servo] 0.1 release criteria

On 8/2/13 12:23 PM, Jack Moffitt wrote: We are starting to plan what will go in the first numbered version of Servo. The proposal is to gate the initial release on a set of criteria, and after that releases will be time based and include whatever features are done by the release date (much like R

Re: [dev-servo] 8/5 meeting - quadtree leak; element binding conversion; parallel layout; 0.1 criteria; benchmarks; acid1 status

On 8/6/13 2:19 AM, David Bruant wrote: I have never even considered writing a page with hundreds of rendered iframes and I don't think I have seen it in practice. Testing perf edge cases is important to be sure the browser doesn't suck in these circumstances, but the average case should receive m

Re: [dev-servo] 8/5 meeting - quadtree leak; element binding conversion; parallel layout; 0.1 criteria; benchmarks; acid1 status

On 8/6/13 2:19 AM, David Bruant wrote: Testing perf edge cases is important to be sure the browser doesn't suck in these circumstances, but the average case should receive more focus IMHO. Especially in early stages. Also I'm not sure I fully agree with this statement, unqualified. We should a

Re: [dev-servo] Parallel builds

On 8/9/13 4:00 PM, Josh Matthews wrote: A brief twitter observation convinced me to dig into our build system effeciency. First off, some numbers from a -j10 build after a `make clean`: origin/master: real3m51.867s user3m41.425s sys0m10.434s jdm/parbuild [1]: real2m36.697s user

[dev-servo] The road to Acid2

Hi everyone, Now that we've essentially passed Acid1 (once one remaining pull request is merged), Acid2 is on the horizon! I've identified the issues that were immediately apparent between us and Acid2 and created a wiki page and a milestone to track our progress: https://github.com/mozilla/

Re: [dev-servo] The road to Acid2

On 8/26/13 9:11 PM, L. David Baron wrote: Is it worth prioritizing having working incremental layout so that you can benchmark the architecture for doing incremental updates (and make sure it performs acceptably) over these tasks that you list? (As somebody following from a distance, I'm more co

Re: [dev-servo] The road to Acid2

On 8/27/13 1:48 AM, Simon Sapin wrote: Maybe also writing modes / vertical text? Even if the actual feature is not a priority, it might be easier to rewrite the layout code to use logical keywords (eg. measure/extent instead of width/height) while we don’t have much layout code. http://dev.w3.o

[dev-servo] Ideas for incremental flow tree construction

Hi everyone, I wrote up some rough ideas for parallel, incremental flow tree construction in Servo. Please feel free to add or remove data, poke holes in it, etc. :) https://github.com/mozilla/servo/wiki/Incremental-flow-tree-construction Patrick _

Re: [dev-servo] team meeting agenda bashing

On 8/30/13 6:01 PM, Jack Moffitt wrote: I'm working on the agenda for the upcoming team meeting in Mountain View. What do people think about focusing our efforts getting some subset of Dromaeo working? I suspect this would involve implementing DOM APIs and measuring performance. Benchmarks of

Re: [dev-servo] Partial layout worth thinking about?

On 9/10/13 12:31 PM, Boris Zbarsky wrote: I generally consider it pretty intractable, but the Blink folks are trying it: http://code.google.com/p/chromium/issues/detail?id=283623 The idea is that a layout flush should only do layout until the part we care about is stable. Or something. Could

Re: [dev-servo] Partial layout worth thinking about?

On 9/11/13 9:12 AM, Boris Zbarsky wrote: Or bail out of it, either way. For the use cases here bailing out would be better, since people tend to do this sort of thing in a loop. Yes. But ideally it would be nice to be able to resume layout where you left off. According to the bug, Chrome's im

Re: [dev-servo] Partial layout worth thinking about?

On 9/11/13 9:35 AM, Boris Zbarsky wrote: This fails if the node is inside an overflow:auto block that does multipass layout to figure out which scrollbars to show: in that situation there will be multiple FinishAndStoreOverflow() calls in Gecko and presumably multiple assign-heights traversals in

[dev-servo] Parallel layout in Blink

Interesting work on Blink (thanks to Jack): https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/-TBnz3LJiGY This overlaps with much of the layout and parallel constraint solving stuff that Servo is doing. I am not sure that performing parallel layout purely on the block level will

[dev-servo] Fwd: Re: Fast path for text shaping--worth it?

cc-ing the list here. This is relevant to the "shaping fast path" discussion that came up in the meeting. Patrick Original Message Subject: Re: Fast path for text shaping--worth it? Date: Tue, 17 Sep 2013 09:02:34 +0100 From: Jonathan Kew To: Patrick Walton CC: Jo

Re: [dev-servo] 9/23 meeting - leaks, crashes, reflow performance, demos

On 9/23/13 11:57 AM, Boris Zbarsky wrote: It's hard to say more here without seeing the actual testcase being measured. Here it is: https://gist.github.com/pcwalton/6695691 I deliberately crafted it to avoid shaping and floats so that, to the greatest extent possible, it's testing the core b

Re: [dev-servo] 9/23 meeting - leaks, crashes, reflow performance, demos

On 9/25/13 3:09 PM, L. David Baron wrote: So I think it's probably possible to do a good bit better than current Gecko. And I also think it might be worth seeing how Gecko does on your test before/after the 2004 margin collapsing changes. I just did some more work to optimize our method dispat

Re: [dev-servo] update layout-free CSS from workers

On 10/13/13 10:57 AM, Dave Herman wrote: Interesting proposal from Google: https://github.com/ianvollick/animation-proxy/blob/master/Explainer.md Some random thoughts: * I guess the obvious cross-thread GC problem is remedied by making animation proxies weak, so they decay to no-ops when the

Re: [dev-servo] update layout-free CSS from workers

This did make me realize something, however: If there are a subset of CSS properties that can be changed from a worker thread, then those layout properties can be changed from the main thread as well, without a trip through layout. In other words: When changing something like transform, if the

Re: [dev-servo] update layout-free CSS from workers

eliminate jank. Patrick Andreas Gal wrote: > >How does this relate to the async animations we are already performing >on the compositor thread today? Isn't that sufficient for most >animations people want? (transform, opacity). > >Andreas > >On Oct 13, 2013, at 1:43 PM,

Re: [dev-servo] update layout-free CSS from workers

On 10/13/13 6:23 PM, Robert O'Callahan wrote: Gecko (and Webkit/Blink) already do stuff like that, insofar as scripted transform changes and changes to certain other properties do not cause reflow. When there are multiple changes, some of which require reflow and some of which don't, you need to

Re: [dev-servo] update layout-free CSS from workers

On 10/13/13 6:20 PM, Robert O'Callahan wrote: On Sun, Oct 13, 2013 at 4:03 PM, Patrick Walton mailto:pwal...@mozilla.com>> wrote: * I foresee tricky synchronization problems to keep the DOM objects that proxied objects in workers refer to in sync with what's happe

Re: [dev-servo] update layout-free CSS from workers

On 10/13/13 3:30 PM, Brendan Eich wrote: Patrick Walton wrote: Ultimately, as I said before, I think there is no sidestepping the need for a truly multithreaded browser engine to eliminate jank. Has this been rejected just for now, in a pragmatic way, or more decisively (for a longer term

Re: [dev-servo] New style system and regressions

Huge kudos! This is an extremely exciting milestone. Thanks so much for all your hard work! Patrick Simon Sapin wrote: >Hi dev-servo, > >The new style system (CSS parsing, selector matching, cascading, >inheritance and computed values) that I’ve been working on for a few >months is finally he

Re: [dev-servo] 10/28 meeting - os x, rustpkg, ssl, interning, retina, reflow performance, android compositing

On 10/29/13 8:52 AM, Simon Sapin wrote: Le 29/10/2013 15:06, Josh Matthews a écrit : https://github.com/mozilla/servo/wiki/Meeting-2013-10-28 Retina display P: In the short term, we should change the Au that CSS reports. I disagree. Au as I understand it is one 60th of CSS px, always. High

Re: [dev-servo] TreeNode and the script/style split

On 10/30/13 3:26 PM, Jack Moffitt wrote: Right now we have this TreeNode abstraction that has been around for a long time and has lost its original purpose (whatever that was). It's only job right now appears to be to break the cyclic dependency between the script and style crates. Does anyone h

Re: [dev-servo] Segmentation fault is caused by 'No appropriate framebuffer config found!'

On 10/31/13 12:27 AM, Deokjin Kim wrote: Dear all, When I executed servo, I met segmentation fault. It's caused by 'No appropriate framebuffer config found!'. We've seen problems with some GPU drivers on Linux not being able to handle binding X pixmaps to RGBA textures. I assumed that in 2013

[dev-servo] Event loop and compositor communication

Hi everyone, Currently Servo's event loop is a poll model on a fixed timer. This is done for historical reasons: originally the Rust runtime did not interoperate very well with native UI event loops and we had no choice. This is very bad—it precludes putting the browser engine into production

Re: [dev-servo] Event loop and compositor communication

On 11/2/13 8:26 AM, Niko Matsakis wrote: At a high level, it seems reasonable, but I don't have a good grasp over what kinds of messages are going over these channels and with what frequency. That seems to be crucial with respect to judging the perf effects of moving to a serialization scheme.

Re: [dev-servo] Meeting 2013-11-04: mac builder failure, priorities (C++, layout, parallelism, rustpkg, embedding, graphics)

On 11/5/13 2:11 PM, Robert O'Callahan wrote: I had a discussion with pcwalton and kmc yesterday about string interning. The concurrent cuckoo hash table is cool but maybe not the right fit for the browser workload for a couple of reasons: a) interning lookups are mostly not on the hottest paths.

[dev-servo] Preliminary parallel-layout branch

Hi everyone, I have a preliminary parallel-layout branch here: https://github.com/pcwalton/servo/tree/parallel-layout Currently it only runs bubble-widths (computation of minimum and preferred widths) in parallel, and some things (such as text) are turned off due to not being thread-safe yet.

Re: [dev-servo] Removing shared boxes from the DOM

On 12/3/13 12:07 AM, Josh Matthews wrote: Ms2ger and I have been working on this on and off, and the Event hierarchy is looking very nice so far: https://github.com/jdm/servo/commits/jsmanaged . It even builds and passes tests, so we should be able to continue converting this piece-by-piece. Ther

Re: [dev-servo] Removing shared boxes from the DOM

On 12/3/13 12:54 AM, Josh Matthews wrote: I don't entirely understand what this means, either in theory or in practice. So the issue is that the Rust compiler assumes a couple of things around `&mut`: 1. No `&mut` aliases any `&` (because then `&` wouldn't be immutable). 2. No `&mut` aliase

Re: [dev-servo] Removing shared boxes from the DOM

On 12/5/13 9:05 AM, Josh Matthews wrote: In my mind, the biggest improvement here is that we can actually have lists of JSManaged, whereas before we could only store ~[AbstractNode] with the handwave-y guarantee that all of the nodes should also be elements. I also find the new checked casts much

Re: [dev-servo] Removing shared boxes from the DOM

Right, it's not done yet. This is a nicer workaround than the workaround we had before, essentially. Patrick Bobby Holley wrote: >To clarify, this stuff doesn't use the new inheritance stuff that's >going >into Rust, right? I assume that stuff isn't done yet? > > >On Thu, Dec 5, 2013 at 9:05 AM

Re: [dev-servo] Removing shared boxes from the DOM

On 12/6/13 10:12 AM, Niko Matsakis wrote: I am not especially happy with these two changes. They feel hokey and special purpose. I guess the best sol'n depends on the degree of static safety we want. Without something like the `'return` lifetime, I'm not sure how we can guarantee that `Root` valu

Re: [dev-servo] Removing shared boxes from the DOM

Devirtualization isn't necessary if we use unboxed closures. Patrick Niko Matsakis wrote: >On Fri, Dec 06, 2013 at 10:17:40AM -0800, Patrick Walton wrote: >> Wouldn't these data structures be instead traced by the JS GC? ISTM >> if you are putting roots in a data str

[dev-servo] Storing pointers to flows and boxes inside the DOM

Hi everyone, I filed an issue with thoughts and ideas on how to do this in Servo going forward: https://github.com/mozilla/servo/issues/1412 Feedback and comments, either here or on the issue tracker, are very welcomed! Checking my reasoning and ideas for the TBD areas are particularly valua

Re: [dev-servo] Storing pointers to flows and boxes inside the DOM

affect the safety of the design as long as the "flow-to-be-reused" is appropriately sanitized at the Rust type system level to avoid use-after-free of dead child flows/boxes. Patrick Boris Zbarsky wrote: >On 12/14/13 5:18 PM, Patrick Walton wrote: >> Feedback and comments

[dev-servo] RFC: Rename "rendering" to "painting"

Hi everyone, Preface: This is a total bikeshed. I was wondering whether we might want to rename "render" to "paint". The issue is that "render" means different things in different browser engines and so the term is kind of confusing. As far as I can tell "render" in Gecko means either "layout

Re: [dev-servo] Speculative parallel CSS lexing

On 2/4/14 9:15 AM, Daniel Hackney wrote: My message was delayed for a few months in the purgatory of moderation, so the info in the original email is somewhat out of date. I wrote a summary of my findings in the file "capstone.pdf" here: https://db.tt/JNcSdrIe The moral of the story is that I g

[dev-servo] Leaf set construction is probably unnecessary

(Copy and paste from GitHub issue #1650 because I figure mailing list discussion is potentially more fruitful than GitHub issues for design discussions.) I realized this morning that we can probably avoid the need for a leaf set by intertwining selector matching and flow construction, and flow

Re: [dev-servo] Leaf set construction is probably unnecessary

nvoke them separately without having to duplicate code. Patrick Boris Zbarsky wrote: >On 2/9/14 1:24 PM, Patrick Walton wrote: >> (2) it's easier to benchmark >> style recalc against Gecko and WebKit when it's not intertwined with >> intrinsic width calculation. > >

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On 2/10/14 12:41 PM, Robert O'Callahan wrote: What exactly do you mean by "font collection loading"? If you ask the right questions I can explain how it works in Gecko :-). Sure thing. Sorry for the delay here, I needed to profile and re-familiarize myself with Servo's code :) I'm on a Mac,

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On 2/11/14 8:04 PM, Jack Moffitt wrote: * `CTFontCollectionCreateMatchingFontDescriptors` - constructs the query used to ask the OS which fonts are available. This is ultimately called from Servo `FontContext::get_resolved_font_for_style()`, called during frame construction for text boxes. * `CT

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On 2/11/14 9:42 PM, Robert O'Callahan wrote: Obtaining the list of platform fonts is incredibly performance-sensitive. We have a gfxPlatformFontList object for this, which caches the font list indefinitely. When the system notifies us of a font list change, we rebuild our font list from scratch,

Re: [dev-servo] 2/10 meeting notes (interning; embedding; beforeunload; acid2 status; testing status; parallelism status; easy bugs; rust upgrade; docs)

On 2/12/14 12:06 PM, Robert O'Callahan wrote: For Servo, I would pull the font.name prefs from all.js to get a fixed list of per-language font names to use for fallback and default fonts, and not implement platform font lists for now and hopefully not ever. Sadly we already h

[dev-servo] Parallel hazards with absolutely positioned blocks

Hi everyone, Pradeep's excellent pull request [1] for absolute positioning raised some thorny issues relating to solving geometry constraints for absolutely positioned blocks in a parallel setting. The fundamental issue is that absolute positioning can depend not only on width and height of t

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

On 2/13/14 2:42 PM, Boris Zbarsky wrote: Then you go through this list (this part should parallelize pretty nicely, btw, except for the overflow area updates on parents) and reflow them all, since now you know their containing block sizes, and you update overflow areas. Again, if there are abs p

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

For the first concern, I realized that pages like that are going to be sequential no matter what we do, of course, because of the way parallel tree traversals work. So never mind there. The O(n^2) update of overflow areas still concerns me though. Patrick Walton wrote: >On 2/13/14 2:42

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

the list. It also avoids the O(n^2) hazard by computing overflow for each frame exactly once. How does this sound? Patrick Patrick Walton wrote: >For the first concern, I realized that pages like that are going to be >sequential no matter what we do, of course, because of the way para

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

On 2/13/14 4:54 PM, Robert O'Callahan wrote: On Fri, Feb 14, 2014 at 1:43 PM, Boris Zbarsky wrote: On 2/13/14 5:56 PM, Robert O'Callahan wrote: 2) Fragmentation. With something like overflow:fragments, absolute positioning can affect the number of fragments you generate, which can affect the

Re: [dev-servo] Parallel hazards with absolutely positioned blocks

On 2/14/14 4:15 PM, L. David Baron wrote: The overflow:fragments spec should probably either (a) say the same or (b) require fragments following an absolutely positioned fragment to also be absolutely positioned. I'm in favor of (b), I think. (I think there might also need to be a constraint ab

[dev-servo] Quantifying the impact of floats on parallelism

Hi everyone, I did some preliminary investigation into how much floats are likely to impact parallelism in the wild. I wrote a quick script [1] that looks at how many nodes could have their heights assigned in parallel and ran it on the Alexa Top 50 in the US. I assume that a node can be lai

  1   2   3   >