Re: [dev-servo] Categorizing Stylo reftest failures
On 7/24/17 1:53 AM, Manish Goregaokar wrote: and the styloVsGecko / issue (which does not block landing since it's a slight discrepancy between stylo and gecko) Looks like it's a difference in vertical alignment. How sure are we that this won't affect web pages outside of media controls? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Consider using GitCop
On 6/2/17 12:34 PM, Michael Howell wrote: $ echo -n "Allow style sharing elements with ID selectors" | wc -c Misleading, unfortunately, because that changeset on its own doesn't allow anything of the sort. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Consider using GitCop
On 6/2/17 11:50 AM, Anthony Ramine wrote: Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) Just so we're clear, 50 characters is about 9 words. - Fix style sharing of elements affected by id selectors No, that's not what it does. Doing _that_ requires 4 separate changes, of which this is but one. - Share styles of elements affected by id selectors (only?) No, that's not what it does either. Again, it's a step on the way to doing that. It seems to me like the "50 character" rule is pretty hostile to fine-grained changesets, basically. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Consider using GitCop
On 6/2/17 5:18 AM, Anthony Ramine wrote: In the following screenshot, you can see one doesn't even know what that commit is supposed to do from its title, because it is way too long to be informative. OK, what is the proposed cap on first line of commit message? Everything I've seen suggests the first line should be a one-sentence simple summary of what's going on. The fact that github insists on cutting it off to pretty short lengths, shorter than most sentences, is a bit unfortunate. Or concretely, what would you say one should use instead of "Being affected by id selectors should not prevent an element from being inserted in the style sharing cache" as a first line? I also want to argue that the very "bug X - " prefix is counterproductive in Servo commits If we don't propagate those servo commits as separate commits to the Gecko side, then I agree. I've just been putting the full bugzilla link in the non-first line of the commit message. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Embedding Servo - features of interests
On 4/17/17 12:09 PM, Milan Raj wrote: It would be great to have more control externally to know and control when records are added or removed from the undo / redo stack. https://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html was an abortive attempt to create a spec for this sort of thing, for what it's worth. It hasn't really gone anywhere, and may or may not actually be the right direction, but may be worth looking at anyway, for inspiration if nothing else. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Partial layout flushes
On 3/27/17 12:05 PM, Jack Moffitt wrote: Yes, but since layout runs in parallel and is pretty fast, I'd think the common case was that it would be done by the time it got the second request. I doubt layout is "pretty fast" on the scale involved here, which is "hundreds of times per frame". But I'm obviously willing to be convinced otherwise by measurements. ;) My guess is that it will be hard to know whether another synchronous query is coming and which mode should be engaged. Yes, I'm not saying there are easy solutions here. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Partial layout flushes
On 3/27/17 10:36 AM, Jack Moffitt wrote: Responses to layout queries are just sent messages (if layout needed invoking to answer them). It is possible to send them early as soon as the relevant data has been computed. Servo does not do this currently though. An initial implementation could just reply with the answer and then keep running layout to completion. I assume this will still require styling + 2 tree passes in most cases, but the last pass will be shortened. That would be an interesting start, yes. How would it handle the common failure mode I'd really like to address, where a page does: 1) Modify style. 2) Ask for layout data. 3) Modify style. 4) Ask for layout data. At step 4, will we just need to wait for the layout from step 2 to complete before we can start the new restyling pass? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Error on creating new tests for Mutation Observer
On 3/16/17 7:35 PM, Krishna karthick Balaji wrote: I am trying to write tests for MutationObserverAPI (https://github.com/servo/servo/wiki/Mutation-observer-project) Are these tests covering something not already covered by the various dom/nodes/MutationObserver* tests? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Async HTML parsing
On 3/2/17 2:40 PM, Nikhil Shagrithaya wrote: Shouldn't it be possible to extend speculative parsing to continue parsing HTML instead of just fetching other resources? For what it's worth, Gecko does this: speculatively tokenizes off-thread even if the parser is blocked. If a document.write() of an unbalanced subtree happens that means throwing away the speculative tokenization, of course. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] string-cache (string interning) is now generic
On 11/3/16 4:30 PM, Simon Sapin wrote: Servo defines: type AttrValue = std::string::String; type Identifier = servo_atoms::Atom; type ClassName = servo_atoms::Atom; type LocalName = html5ever_atoms::LocalName; type NamespacePrefix = html5ever_atoms::Prefix; Ah, perfect. That all makes sense, then. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] string-cache (string interning) is now generic
On 11/3/16 3:17 PM, Simon Sapin wrote: An important aspect is that atoms with different static sets are different Rust types. Just to check that I understand correctly... Are element names atoms? Which static set do they come from? Presumably the html5ever one? When parsing CSS selectors, are tag name selectors atomized? Which static set is used for that? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Fwd: Maintaining a list of debugging targets in the debugger.
On 9/19/16 6:49 PM, Jim Blandy wrote: grandparent (origin O) parent (origin P, P != O) child (origin O, same as grandparent) then the grandparent and the child are in the same UoRSOBC. The grandparent can say `frame.contentWindow.frames[0]` to get its grandchild frame.contentWindow should return null in this case. But the grandparent can do window[0][0] (aka window.frames[0].frames[0]) to get the grandchild. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Servo testing as part of PhD dissertation
On 9/7/16 11:55 AM, Geoffrey Sneddon wrote: There are plenty of rendering bugs that don't involve text, and practically if you're generating arbitrary web pages it's easy to solve all of those problems by simply not including text (though you'll need to give boxes explicit heights!). Does using the Ahem font still leave noticeable font rendering differences between browsers? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
On 6/22/16 11:17 AM, Manish Goregaokar wrote: We don't close down the tree except for CI fires Yes, I understand your model. You don't have to explain it to me. I was just pointing out that for normal commits you prefer the model of test-each-thing, but for style system you would prefer the model of just-test-every-so-often. I realize the reasons for that too, but I think we have a different evaluation of the resulting costs. In particular If the tests fail for a PR, it is taken out of the queue until it is fixed and reapproved. My question is what happens when a PR stalls like this for months because by the time it's fixed something else has broken. I expect this to happen every so often when the PR is the style system merge. m-c does not have this model, and I'd also like to prevent marrying our CI times to those of m-c, or being affected by m-c backouts. I understand and sympathize with that. That's why I like the sync model, it concentrates all of the conflict in one operation At the cost of possibly making that operation impossible to complete. instead of distributing it everywhere and making every PR that touches anything that affects style suffer. The syncing operation is also async (ha!) -- while being performed other Servo work can continue. Which is what may well make it impossible to complete the sync. Sending PRs which look like they need testing to gecko-try should catch most issues, the only remaining issues are when a PR (like a wrong refactor, or something) which wasn't sent through gecko-try breaks stylo, or when something on Gecko's vendor dir managed to land between the time the Servo PR was tested and landed. I postulate these two cases will be relatively rare, and these will be the only times the sync fails. Right, I think our fundamental disagreement is a matter of assumptions about frequency. I hope that you're right about these failures being rare, but expect that you're wrong and worry about the failure modes if you are This is actually pretty close to the proposed model in the doc, but it gives a lot more leeway in when the sync should happen. Well, and assumes that reviewers are decent at evaluating the "may need stylo testing" predicate. The proposed model is basically equivalent to this except syncs are mandatorily part of any PR that affects style, and can make the queue clog up. Here based on various factors you can choose not to sync (e.g. if the queue is already full; you can wait to trigger the sync until it empties, or if the PR probably doesn't need a sync). I agree that having such flexibility is not unreasonable. We can then by trial and error figure out the best policy for when to sync and when not to sync balancing the need for fast CI times and the need for things to not cause colossal merge conflicts. That seems fair. Ideally we would end up with a "sync pretty much every time" setup. Sure they can, but they should be less likely to :) That hasn't been my experience with refactorings at all! We will still have the full CI run on a sync so these will get caught, just not immediately. Right. The question is how much piles up before a sync. So more granular syncs are better if they can be arranged. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
On 6/22/16 9:52 AM, Manish Goregaokar wrote: This has one significant drawback: it places a pretty serious burden on whoever performs the sync. In particular, in addition to merging the actual code (already needs some expertise), they become responsible for handling any test failures that arise as a result of changes in the "other" repo. I personally prefer having to do a controlled tough sync every now and then over the lockstep thing. As a matter of dealing with test breakage and how it's resolved, do you also prefer doing a bunch of commits and only then running tests, and if they fail closing down the tree until it's all resolved? If not, how is this substantively different? I realize it's different in a practical sense because the costs are higher than normal per-commit testing, of course. Also, we can alleviate part of this by doing syncs smartly. Just because you *can* make a change without touching Gecko CI doesn't mean you should :) If the reviewer thinks that a change to Servo style is expected to affect Gecko, a gecko-try run should be made too with a sync applied (this automation is easy enough to write). Once it merges, perform a sync if you feel it necessary. This lets changes like refactorings, dependency updates, etc become less of a pain You make it sound like refactorings don't introduce bugs. ;) -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
On 6/22/16 8:47 AM, Manish Goregaokar wrote: Changes to webrender would be made in m-c or servo/webrender, whichever is more convenient, and there is a periodic sync operation. This has one significant drawback: it places a pretty serious burden on whoever performs the sync. In particular, in addition to merging the actual code (already needs some expertise), they become responsible for handling any test failures that arise as a result of changes in the "other" repo. The way this is handled in wpt, at least for the Gecko <-> wpt two-way sync goes like this as far as I can tell: 1) One side (the wpt side) has pretty trivial integration tests: it basically just tests filename length. So if Gecko-side changes break those tests fixing is not too terrible. 2) The other side (the gecko side) has a way to annotate failing things, and whatever starts failing after a change on the wpt side is just annotated as failing and checked in that way. I think this is pretty broken, but that's what we're doing right now... Needless to say, something like the style system would have somewhat different constraints on whether it actually needs to pass tests (for real, not for purposes of the test harness; just annotating stuff as "known fail" and moving on is not really what I anyone is looking for here). But even with the behavior above wpt merges are a huge time-sink. Just talk to jgraham. Depending on how often breakages are introduced and how long it takes to resolve them, this can make it completely impossible to merge. I guess if that happens you can start telling people to stop changing the style system for a while while the backlog is sorted out, etc. But what this basically means is that instead of having your tests-are-failing pain on the changesets that cause the problems you have it all in a huge lump every so often that takes days to weeks to detangle. I really wish we had decent data here on how often breakages would arise in practice, and specifically how likely it is that a change that passes Gecko's integration tests fails Servo's and vice versa That would give us at least some idea of how often we'd need to merge to prevent things snowballing. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
On 6/21/16 12:20 PM, Lars Bergstrom wrote: I'm still a bit worried about this unless the revert rate comes down pretty significantly for any shared branch between servo and gecko. That's fair. We should certainly not make inbound that shared branch! :) But we'll see how the proposals come out. The last I heard, we would be co-landing servo bits to the autolander branch, which was intended to be mostly backout-free. Either that, or a dedicated integration branch for servo stuff, if the sheriffs are willing to deal with that. At least that way backouts would presumably only happen if a change (1) lands in servo, which means it's passed the servo pre-landing tests and (2) that change breaks Gecko. We can hope this is rare. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
On 6/21/16 8:34 AM, Lars Bergstrom wrote: If a backout lands as a `git revert` of the offending commit(s) I'm certainly less concerned, as that's annoying but not impossible for people to continue rebasing against. Right, that's how backouts land. The way it was explained to me (and I may have been misunderstanding!) is that if a batch of changes land on m-i but then fail tests, they are removed and there is the mercurial equivalent of a force-push back to m-i without those changes in the history. No, absolutely not. Backouts due to test failure are done as an `hg revert`. Sounds like something here got miscommunicated. :) I'm aware of exactly one instance of history editing happening on m-i in the time we've been using it. It happened when someone incorrectly pushed a gigantic "test" file that significantly (like 50% if I remember correctly) increased the size of the repo. Obviously just doing a revert on that would do nothing about the problem of it bloating the repo size... This was obviously a much bigger deal than a normal backout, and involved installing commit hooks to block the relevant sha, etc, etc. That workflow made me concerned for people with an open PR, as if the PR was based on master at commit A, commit B lands and they rebase against it, but then B disappears from the history, getting their PR landable again is likely going to require intervention by a git expert. Right, makes sense if you thought we were editing history! But we're not doing that. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Proposed work for upcoming sharing of Servo components with Firefox
On 6/20/16 8:35 PM, Lars Bergstrom wrote: Backouts came up in the discussion, and I tried to make it pretty clear that they are not compatible with a GitHub-style development model (even if you *could* hypothetically do crazy things like force-pushing rewritten histories to master). Wait, why are rewritten histories relevant? A backout doesn't involve rewriting history... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Suggested code review workflow
On 2/3/16 1:46 PM, Josh Matthews wrote: Nikki asked for suggestions for how to review code, so here's my first attempt at writing down a general suggested workflow for reviewing Servo code: https://github.com/servo/servo/wiki/Code-review Somewhere in there, one should read the commit messages too. Probably before reading the code. And if it's not clear from the commit messages what the goal of the code changes is, then they need fixing. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone
On 11/4/15 12:09 PM, Manish Goregaokar wrote: I'd prefer to avoid diverging from the spec wherever possible -- even if other browsers disagree (with the spec and with each other) I think Ms2ger was talking about cases in which the spec disagrees with all browsers, who agree with each other. In which case, chances are the spec is just wrong. Unless it has an explicit note about how it's purposefully disagreeing with the world because it thinks it's better that way. In which case it may still be wrong, of course. Note that there are obvious and fundamental bugs in specs all the time. Pretty much any time I look at a spec for anything at all complicated I find a few. :( -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone
On 11/3/15 4:52 AM, David Bruant wrote: @Manish: additionally, perhaps leave a comment in the open spec bug Oh, yes. Any time the spec does not match reality or sanity, do let the spec author know. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling cases where the spec is inefficient and not followed by anyone
On 11/2/15 2:21 PM, Manish Goregaokar wrote: We have three choices here, we can wait indefinitely until the spec gets fixed, we can implement the spec as is (which require major changes and affect perf or complexity), or we can hope that nobody relies on this behaviour (given that it's not followed by major browsers) and implement it as logically as possible, keeping in line with other browsers (and leaving a bug open about the spec issue). I recommend the third approach: do the sane thing, wait for the spec to catch up. Certainly in the :target case. For the HTMLFormControlsCollection case, you need to implement it for no matter what. The real question is whether to implement it for too, right? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)
On 4/28/15 5:23 AM, David Bruant wrote: Another possibility is for the reporter to make a PR with the test case. Just stop. We're talking about making it _easy_ to report issues, yes? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)
On 4/28/15 10:33 AM, Jack Moffitt wrote: This is an issue, but hasn't hit us much yet. Sure. I assume if it had you would have been dealing with it. ;) It's easy enough to use the ``` syntax to include arbitrary things into a bug report. This is how we often attach logs and such. You can't directly read it from Servo since it's inline in the bug text, but cut and paste is pretty simple and these are small test cases right? :) That fails once you have images involved, unless the reporter converts them to data: URIs. This also fails in various cases that involve strings github may not be able to represent (invalid characters, etc). I agree that it can work in a lot of cases, of course. It's also pretty easy to make a gist (gist.github.com) of whatever you like and link to that from the bug. Ah, I should look into this more. That might be enough. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 4/27 (Reviewable; blog posts; github/BMO; infra issues; Whistler planning)
On 4/27/15 8:38 PM, Josh Matthews wrote: https://github.com/servo/servo/wiki/Meeting-2015-04-27 I've mentioned this a few times, but... For a layout engine, being able to attach an actual testcase to a bug report is _really_ useful once you get out of just build it mode and into fix all the bugs in this thing you built mode. Github issues simply have no way to do this that I've been able to find. You can put testcases on jsfiddle or other such services, but it's really hard to do minimal testcases that way because of all the things those services pull in, it's impossible to test some things (e.g. parser issues, quirks mode) because there's little control over the markup, and there are absolutely no guarantees your testcase will be around in 5 years when you want to see what that code change was trying to fix. This is really a problem I expect you'll want to solve at some point if you want to be able to get useful functionality bug reports and community QA. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Channels and synchronous networking
On 1/28/15 12:33 PM, Josh Matthews wrote: I'm not certain what you're asking. The events come from another thread, so they need through some kind of event queue. Today, that's the per-origin event loop. OK. That means, for example, that you can't navigate away from a page that's in the middle of a sync XHR. At least assuming I understand the setup correctly. If so, that seems clearly undesirable, since a page can simply keep triggering consecurity sync XHRs -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Channels and synchronous networking
On 1/28/15 7:21 AM, Josh Matthews wrote: My current line of thinking is that we send a message to the compositor that puts the pipeline in the modal state and pops up a dialog. Additionally, the message contains a Sender, with the script task waiting synchronously on the corresponding Receiver; when the alert box is closed, the compositor sends a value to the script task that causes it to resume. Does this allow the user to close or navigate the tab and have the alert box auto-dismiss? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Channels and synchronous networking
On 1/27/15 5:46 PM, Josh Matthews wrote: We don't have the notion of a global event loop or anything. We effectively have an event loop per script task (ie. event loop per TLD), but no ability to spin it arbitrarily at the moment. How do you plan to implement alert()? Do you plan to allow an alert model like Firefox, where the alert doesn't freeze the entire UI? Realistically, I think you actually want multiple event queues even per script task (akin to the task queues in the HTML spec) and the ability to selectively shut them off temporarily... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Async networking choices
On 1/12/15 2:39 PM, Josh Matthews wrote: the obvious downside is that a tab's event loop will be cluttered with constant attempts to poll for incomplete network responses during page load. Not just during page load. I expect this to peg the event loop on any site that uses long polling (see http://en.wikipedia.org/wiki/Push_technology#Long_polling) and other Comet (http://en.wikipedia.org/wiki/Comet_%28programming%29) techniques. Also anything that uses websockets or server push, if those are implemented on top of this pull network infrastructure. Some general thoughts on what consumers might want: 1) Gecko currently has an incremental consumer for HTML parsing, non-incremental ones (buffer up all the data before acting) for CSS and script. Not sure about imagelib. 2) In Gecko, the JS folks want to make the script consumer incremental so they can kick off syntax parsing (or a full compile in the case of asm.js) in parallel with the network load. 3) In general, the more you're doing stuff on multiple threads the more it makes sense to do work on the results of a network load (optimistically?) in parallel with the network load For example, if Gecko's charset converters could run off the main thread, I would totally be experimenting with doing streaming charset conversion for scripts and stylesheets as the data comes in, even if our consumption of the resulting Unicode remains non-incremental. 4) Blocking on network is a smell to me unless every single network request lives in a separate task. Then it might make sense for cases that don't need incremental consumption. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Style invalidation in Blink reading
Apparently Blink has been changing how they handle style invalidation on DOM mutations. https://docs.google.com/document/d/1vEW86DaeVs4uQzNFI5R-_xS9TcS1Cs_EUsHRSgCHGu8/edit?pli=1#heading=h.xa3ovcncd2vp has a writeup of sorts for those who are interested. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Invalidation test cases?
On 10/28/14, 1:15 PM, Patrick Walton wrote: In other words, what are examples of the major pain points that DLBI was designed to handle in Gecko? You should double-check with Matt Woodrow, but three things come to mind: 1) Pre-DLBI, invalidation code was scattered all over layout and it was easy to forget to invalidate. 2) We ended up invalidating too much due to transient layout changes of various sorts that triggered an invalidation and then were undone by the layout algorithm (e.g. temporary repositioning of things, size-measuring layouts, etc). 3) The old invalidation setup had poor performance. Keep in mind that the old setup in Gecko was aiming at correct, but invalidating the minimal possible area. So any time something changed size/position during layout we'd walk all the way to the painting root computing the now-invalid region in that painting root's coordinate system, then store it there. All those tree-walks were the source of problem #3. The fact that they had to be at all places that changed size/position during layout led to #1 and #2. https://bugzilla.mozilla.org/buglist.cgi?f1=dependsonlist_id=11461782o1=anywordssubstrresolution=FIXEDquery_format=advancedv1=539356 has a list of some bugs that DLBI fixed that might be worth looking at. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes 10/20 (work week agenda; intermittent failure troubles; inversion of control; sync script loading; document load tracking)
On 10/20/14, 1:29 PM, Josh Matthews wrote: https://github.com/servo/servo/wiki/Meeting-2014-10-20 I'm not sure I understand the sync script bit. You don't want to block user interaction with the page while fetching a script. You also don't want to block the parser tokenization prescan, preloads from that prescan, etc. All that should be blocked is DOM construction from the parser. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] (Lack of) XML parser
On 10/14/14, 12:26 AM, Simon Sapin wrote: Is there anything other than SVG that might require an XML parser XMLHttpRequest and DOMParser, no? but it sounds unlikely that real content relies on an entire document failing to parse. XMLHttpRequest not only relies on it, but relies on the exact behavior of browsers in not-well-formed cases, complete with browser sniffing because browsers don't agree on it, last I checked. :( -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing
On 10/6/14, 3:53 AM, Cameron Zwarich wrote: Where do most of the small strings larger than a single character that benefit from the inline small string optimization originate, the DOM or user JS code? That's a good question. When the optimization was added, strings that originated in the DOM never ended up using the inline small string optimization (because they ended up as external strings instead). Even now, strings returned via nsAString out params (which is most APIs) end up as external string. The one case when DOM-provided strings get inlined on the JS side is when we're using a DOMString out param (which a small number of DOM methods use). See https://bugzilla.mozilla.org/show_bug.cgi?id=934544. None of which really answers your question, since it depends on the call frequencies of DOM methods. But I expect that JS-originating strings dominate here. Could be measured. Note that short in this case is 11 utf-16 code points for non-latin1 strings and 23 bytes for latin-1 strings, which actually covers a surprising number of strings that occur in real life. Thanks for the reference. That function takes a char16_t*, but now that they’ve done the Latin1 optimization, it seems like it should be possible to also make a Latin1 variant. Absolutely. https://bugzilla.mozilla.org/show_bug.cgi?id=1038099 is related but distinct; worth filing an explicit bug on a latin1 external string version. There is an interesting question of whether it will ever be a good idea for a JS engine to make something like WTF-8 its native string type, or if the difficulties with random access outweigh the advantages. It seems like a daunting task to do that at this point for Gecko / SM, even if it would work in theory. Yeah, coevolving Gecko and SpiderMonkey here is a pain without boil-the-ocean kind of patches. :( That said, we've considered doing it; the hard part would be avoiding performance problems during the (probably longish) transition period when conversions have to happen some places. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] The current scrolling model
On 10/6/14, 7:44 PM, Boris Zbarsky wrote: Just to check, what's the plan for doing overflow: sticky? I mean position: sticky, of course. ;) -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] WTF-8 encoding for DOM strings and HTML parsing
On 10/5/14, 2:27 PM, Cameron Zwarich wrote: I am opposed to anything that requires string copies between the DOM and JS The only way to do that with SpiderMonkey in its current state is to use JSString for your string type. You cannot safely grab the chars from a SpiderMonkey string and hold that pointer across a GC operation, because the GC might move the string data in memory. Gecko used to not copy the string on calls from JS to C++, and we had to give up on that and just copy. Now for return values from C++ to JS we do still avoid the copy. But we also have the one-slot cache which is a big win; you should definitely do that no matter what else you do with return values... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] rust-http, Teepee, and Fetch
On 7/18/14, 4:10 PM, Manish Goregaokar wrote: - Rewrite the Header class to contain bytes Note that you need header bytes for web APIs like XMLHttpRequest. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Distribution of CSS properties in style structs
On 5/29/14, 11:39 AM, Simon Sapin wrote: I’m aware that every style struct must contain either only inherited properties, or only reset (non-inherited properties). Other than that, what’s the guiding principle to decide how many structs to have, and which properties go where? Initially the idea was to group properties that are likely to be set together into structs (because then setting them will allocate the smallest number of things possible). Also, color was its own struct to ensure that it could be cached in the ruletree (since it's an inherited property, adding more props to the struct would make it very unlikely this could happen). Since then people have been adding things somewhat willy-nilly. I've claimed for several years now that we should reevaluate how we store this stuff in Gecko. Why not have every longhand property in its own struct, sharable separately? Keep in mind that we're talking about computed style. That means you need values for all longhands. Right now a style context has to point to 20-ish structs, so ends up with 20 words worth of pointers in it (except in cases where we optimize out not having any reset structs in the style context itself). If we had to separately point to each longhand's value, a style context would have several hundred words of pointers in it. So that's the main guiding principle to deciding how many structs to have: too many and you need too much memory to keep track of them; too few and you have no meaningful sharing. In Gecko, additionally, computing a struct has some constant overhead (walking over the rule tree) and hence structs that are too fine-grained have too much computational overhead. This is one reason we put all the things typically needed to construct a frame in the Display struct, by the way... Is there something you’d like to change in Gecko’s distribution, but don’t because making the change would be too painful? The primary question is what the distribution should be. If the original goals are maintained, that involves measuring which properties are set most and which are correlated with which other ones, basically. For other approaches, at one point WebKit had something like these structs, but fewer and smaller, with a big rare data struct. That has some obvious drawbacks too, if you guess wrong on what's rare (or it changes). In general, it's not clear to me what the right storage setup is for computed style. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Memory management in the HTML parser (was Re: DOM rooting is live)
On 5/8/14, 9:06 PM, Keegan McAllister wrote: This is all a bit moot if a parser never lives across a JS operation that could GC. If you want your parser to be able to parse web pages with script tags in them, I don't see how you can possibly avoid GC while the parsing is only partially done... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Table-less string interning
On 4/28/14, 6:02 PM, Keegan McAllister wrote: Ultimately I'm sort of pessimistic about table-less interning, because it proposes to speed up parsing at the expense of layout. A thought. If the goal is to speed up parsing in a separate task by avoiding contention on a table, have we considered a setup where we do part of the work of interning (e.g. computing the hashcode) in the parsing task but then leaving things in that state and finishing up the interning when we ship the data from the parsing task to the task that ends up using the data? This is similar to the approach the JS engine is using for its off-main-thread parsing in Gecko: there's a fixup step when the parsed representation is shipped back to the thread that requested the parse. One issue there is that layout and dom might to share the table, depending on where we do the finish up step of CSS parsing. Is the plan for that to be in the layout task or the DOM task, or sometimes one and sometimes the other? Storing small strings immediate and using a table for the rest seems promising, though. Agreed. I also liked the idea of using Gecko to gather information about interned strings. I'm happy to write up some patches here if people know what info we want to gather. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Table-less string interning
On 4/23/14, 8:53 PM, Brian Anderson wrote: We're assuming nobody is going to be attacking Rust symbols though Oh, right, that's the other worry. We've had security issues in the past due to things like input type=fİle being treated as a file input by some parts of the system but not others. So anything that allows collisions between user-provided things and built-in atoms for attribute names and values is bad. On the bright side, it may be possible to enforce that all built-in atoms are under the 16 char limit and hence not susceptible to collisions. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Alternate way to handle block formatting contexts
On 4/20/14, 2:16 PM, Patrick Walton wrote: Yes, I think it can. :( But there's an easy workaround: just fall back to sequential layout for a subtree if the speculation fails. That will eliminate the cascading series of speculation failures leading to exponential blowup problem and allow parallelism in the common case, without the complexity of interruptible layout. Sounds good. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] character encoding in the HTML parser
On 4/3/14 8:03 AM, Henri Sivonen wrote: Have we instrumented Gecko to find out what the access patterns are like? We have not, but I will bet money the answer is different for benchmarks and actual content... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 3/31 meeting notes (acid 2; Q2 plans; interns; android status; acid 2 post-mortem)
On 3/31/14 8:44 PM, Josh Matthews wrote: https://github.com/mozilla/servo/wiki/Meeting-2014-03-31 A note on tables and pagination: that's a place where you won't really be able to lean on Gecko experience. Or more precisely, table pagination in Gecko is at the state where all pagination is in WeasyPrint: it's one-pass, no handling of dynamic updates. Gecko disallows columnation of tables right now, for example, because we simply can't handle it without crashing if you change anything about your columnset. Of course it's not clear how much you generally want to use of Gecko's pagination setup; it's always seemed pretty complicated to me. Maybe it's just a complicated problem... -Boris P.S. The other thing you should not copy from Gecko when doing tables is how we handle border collapsing. That's one of the remaining nasties in Gecko's layout engine that hasn't been modernized since the bad old days. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] character encoding in the HTML parser
On 3/29/14 6:56 PM, Simon Sapin wrote: Or I guess we could use what I’ll call evil UTF-8, which is UTF-8 without the artificial restriction of not encoding surrogates. http://en.wikipedia.org/wiki/CESU-8 As far as I understand, a parse error in the spec is meant for conformance checkers (validators), not user agents. There is no error recovery behavior, because this is not an error. Technically a UA is allowed to just stop parsing at a parse error. For a browser, of course, that's not web-compatible as you note. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Crazy idea: CSS selector JITting at parse time
On 3/29/14 8:23 PM, Patrick Walton wrote: This is just 29 bytes of code when assembled. This is likely larger than the equivalent `nsRuleNode` The right comparison is not nsRuleNode but nsCSSSelector, right? These are actually pretty bloated in Gecko right now. For example, .foo #a is parsed into a linked list of two nsCSSSelectors. nsCSSSelector consists of 8 words and 8 more bytes, so 40 bytes on 32-bit and 72 bytes on 64-bit. So right now storing the parsed version of .foo #a is 80 or 144 bytes in Gecko. This is not great, and we've been talking about shrinking these for a while, but it's clearly not fatal. The rest of your proposal seems pretty workable. The biggest issue, I suspect, is a maintainability one: it forces a pretty tight coupling between your selector jit and the object layout of your nodes, for any of the tests performed directly in jitcode. For example, your cited jitcode assumes that nodes have a class member and a classCount member and that class points to an array of classes, right? I think it should be possible to minimize the amount of coupling if it turns out to be an issue in practice. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] JST guide
On 3/4/14 5:33 PM, Josh Matthews wrote: I know that some contributors have expressed confusion about the new JST types that are all over the DOM. I've started a guide to try and clear up how to use them; please feel free to suggest further topics or make edits yourself: https://github.com/mozilla/servo/wiki/JS-smart-pointers Some more thoughts on casts: 1) In practice, there are some downcasts that have to be done a lot. Going from Node to Element is pretty common, as is going from Element to particular element types. The simpler these downcasts can be made, the better. Gecko actually uses different patterns for those two cases above. Casts to element types tend to return null if not castable. On the other hand, nsINode::AsElement() will assert IsElement(); callers are expected to check it unless they know out-of-band that it's true. This is largely because of API impedance mismatches: we added Element late, so lots of APIs where the incoming thing is claiming to be a Node but is actually an Element and everyone knows that. If you're going to always check the flag on the cast, you could use the same return Option setup. 2) Is there a way to make passing a JSElement or other Node subclass to a JSNode argument Just Work? Having to manually cast there is a bit of a code clutter PITA... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Parallel hazards with absolutely positioned blocks
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 size of the container of the fragments. Ugh. I thought one of the points of absolute positioning was to not affect the layout of anything If that's not the case anymore, that's _really_ annoying. Let me use this opportunity to remind people that fragmentation and writing-mode are stuff we should be building into Servo now-ish because they affect everything else. Yes! -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] 12/16 meeting notes (review tools, rust upgrade)
On 12/16/13 1:54 PM, Josh Matthews wrote: https://github.com/mozilla/servo/wiki/Meeting-2013-12-16 Some questions on github issues: 1) Do we plan to stick with them for the entire lifetime of servo? That is, does github plan to grow reasonable options for at a minimum release tracking and attaching testcases? 2) If we do not expect to stay with github forever, do we have a plan for exporting the issues and reimporting into whatever issue tracking system we plan to switch to? Losing issues and in particular the discussion that happened around code changes is pretty bad from a future maintainability perspective (we've had it with Gecko, and it sucks). -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Partial layout worth thinking about?
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. The Blink bug highlights some of the issues (e.g. the normal way to handle scrollbars on desktop prevents this optimization). -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] team meeting agenda bashing
On 8/31/13 2:15 PM, Patrick Walton wrote: Dromaeo is pretty old and is basically SunSpider. Dromaeo has a bunch of DOM micro-ish-benchmarks on the one hand and microbenchmarks of common JS libraries (jquery, etc) on the other. Just make sure to run the DOM and CSS portions of it, not the whole thing. Peacekeeper may be better, as it has some DOM and rendering stuff, although it's also full of JavaScript: Peacekeeper doesn't have much in the way of really useful DOM measurements. There is the maze solver benchmark which might be fun to optimize for. This is a selector matching benchmark AIUI. People actually do run this one: http://ie.microsoft.com/testdrive/performance/mazesolver/ It's not a selector matching benchmark at all. It's a benchmark of how fast you can change transform from none to something on a bunch of divs, last I checked. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] team meeting agenda bashing
On 8/31/13 10:41 PM, Jack Moffitt wrote: The DOM ones were specifically what I had in mind. CSS testing probably doesn't make much sense unless we can test stuff we've already implemented in order to compare to the upcoming Rust style system. The vast majority of the tests labeled as CSS in dromaeo, if not all of them, are actually tests of DOM/JS library performance (jquery, prototype, etc). They very rarely involve any actual CSS, except as a side-effect of doing things that JS libraries are supposed to do, like showing or hiding elements by setting display:none. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] DOM object unwrapping without QueryInterface
On 8/30/13 11:55 PM, Josh Matthews wrote:
The current DOM bindings can only fallibly unwrap object types that have
complete WebIDL prototype chains (ie. we can grab the interface ID array
from the object and compare the slot in the chain we care about with the
one we're trying to unwrap). This causes a problem for things like
WindowProxy
Why would you ever need to unwrap a WindowProxy? What would that even
mean?
A WindowProxy is just a JS proxy object; all it does is forward things
through to the Window and implement an indexed getter (and maybe
security checks, in theory, though in practice I think Gecko uses
separate security wrappers for that). In my opinion, there should be no
Rust-side reflection of WindowProxy. Just Window and something to
represent a navigation context.
A possibly bigger problem are things like this:
interface Foo {};
interface Bar {};
Bar implements Foo;
interface Baz {
void doSomething(Foo arg);
};
Baz implements Foo;
where you need not only a type on the native side to represent Foo but
you also need to convert things to that type somehow. For this case
Gecko uses QI right now. The good news is that there are precisely 0
instances of this pattern in Gecko's non-test WebIDL, so it's quite
possible that you can kick the can down the road on this for a bit...
possibly forever. Even if this case does need to be addressed, testing
whether the incoming thing implements Foo would be pretty simple: you
codegen tests that it implements one of the LHS of those implements
statements. See the sort of thing that Gecko's bindings codegen for
mozilla::dom::SVGUnitTypesBinding::_hasInstance, for example. That
handles the does this implement? checks, but leaves the problem of how
to represent on the Rust side unsolved. The right solution may well
just be a union type that can hold Bar or Baz.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] HTML element binding conversion
On 8/8/13 8:18 PM, Josh Matthews wrote: On a related note, saneyuki added support for some element types that don't have their own interfaces and just use HTMLElement. Note that there are other cases where multiple element types all use the same interface that's not HTMLElement (e.g. col and colgroup). So we want support for that sort of thing. I've made a big list (https://github.com/mozilla/servo/issues/703) of similar ones we don't support right now, so feel free to add those to our HTML parser and hook them up to the HTMLElement bindings. Er... that list doesn't look right to me (e.g. it contains col and colgroup, which are not plain HTMLElement, q, which is HTMLQuoteElement, etc). -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Data structures for CSS Selectors
On 7/30/13 3:30 AM, Simon Sapin wrote:
a. A CSS representation of the whole selector list a a string, for the
CSSOM’s selectorText
b. The specificity for the cascade
c. Just the data structures we need for matching
I think this would work, but maybe the cost of a. cancels whatever we
gain in c.?
Well, (a) would increase memory usage but it could be pretty cold memory
so shouldn't affect things like cache pressure and whatnot...
It's worth measuring how much the string in a would be (esp. if we
store it in UTF-8 or something?), as well as measuring how much memory
Gecko's current selectors take.
1) The linked list for SelectorList leads to lots of cache misses as we
traverse it, last we measured.
Would using a vector rather than a linked list fix that?
Possibly.
The other big source of cache misses I recall, by the way, is the
merging loop in RuleHash::EnumerateAllRules...
How about, instead of a big Selector struct, having a list of simple
selectors? This list does not have to be in CSS source order, it could
be reordered in a way that makes matching more convenient (eg. ID
selectors first.)
Fwiw, I _think_ this is more like how WebKit does it last I looked.
struct Selector {
compound_selectors: ~[CompoundSelector],
An interesting question here is how long typical lists of compound
selectors are and whether it's worth trying to do some auto-array-like
thing with an inline buffer for some small size here.
struct CompoundSelector {
simple_selectors: ~[SimpleSelector],
Likewise.
enum SimpleSelector {
Might need to be a little careful about how big a SimpleSelector can end
up; looks like two machine words to handle the LocalNameSelector case,
right? Can we do anything larger out-of-line or something?
In any case, this is more like what we were thinking of, I think.
If I can make a recommendation: instrument a Gecko build with logging
information about selectors and do some measuring/recording of what
selectors we see as you browse for a while. Then we can actually get
some answers on what the memory tradeoffs are here, say, as well as
frequencies at which various constructs are seen and whatnot.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Data structures for CSS Selectors
On 7/29/13 11:38 AM, Simon Sapin wrote: type Namespace = i32 // Is this some kind of interning as well? In Gecko, yes. * Use vectors / arrays instead of linked lists for AtomList, PseudoClassList and SelectorList. (Less allocations) This could make it more difficult to point somewhere in the middle of list (especially in Rust), but I don’t know how important that is. I don't think we generally need to point into the middle of those lists. * Use a single optional string for an ID selector instead of a list. If a (combinator-separated part in Selectors L4 spec terminology) compound selector that has more than ID simple selector selector, either they are all the same and we only need one string (#foo#foo is the same as #foo), or they are different and the selector never matches. #foo#foo has different specificity from #foo, so we need to keep track of that. And #foo#bar never matches, but still needs to be present in the CSSOM * Use a bit field for simple (non-functional) pseudo-classes. Same as ID selectors, repeating the same pseudo-class does not change the selector. (eg. :empty:empty is the same as :empty. This is true for all pseudo-classes defined in Selectors 4 AFAIK.) Again, except for specificity... So I think here are the main issues we have with Gecko's selectors, in terms of your structs, that aren't discussed in your mail: 1) The linked list for SelectorList leads to lots of cache misses as we traverse it, last we measured. 2) The Selector struct is pretty large and most of the stuff in it is unset for most selectors. The vast majority of selectors are tag, id, or class, with namespace almost always '*'. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Inline DOM storage progress report
On 7/24/13 12:16 PM, Josh Matthews wrote:
All DOM objects are represented with |JSManagedWhatever 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.with_mut |whatever| { whatever.owner_document = other_document
}| to modify it.
Hmm. That looks pretty annoying to write for every single property
access, or am I just misunderstanding?
The limit for non-proxies is 16 words, for proxies it's 13.
That's what I thought. 16 words is 128 bytes, right? If each pointer
member is effectively two words because of the COW stuff, that still
means we should be able to fit in 6 or so of them plus a few other
bits... What does the memory layout of a Node look like in our setup
right now?
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Inline DOM storage progress report
On 7/25/13 8:51 AM, Josh Matthews wrote: wrapper: 8 bytes type_id: 16 bytes abstract: 16 bytes out_of_line: 8 bytes layout_data: 8 bytes Hmm. That's a lot smaller than 128 bytes, right? I guess the point is that you could't put _all_ of parent/first/last/next/prev/ownerdoc inline, which is why they're all out of line? What are type_id and abstract? Will 'wrapper' go away in the long term for jsmanaged stuff? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Inline DOM storage progress report
On 7/25/13 9:25 AM, Josh Matthews wrote: type_id is an enum to distinguish between node types, with an inner enum in the element case to distinguish the kind of element. All enums are automatically 8 bytes, and if any variant contains another enum that automatically bumps it up to 16. OK. So I think we should consider doing something like what Gecko (and iirc WebKit) does: nodes have a pointer to a nodeinfo struct which stores all the information that is invariant across all nodes of a given type with a given ownerDocument. This would store the localName, namespace, owner document, nodeName, etc, etc. One issue is that adopting can change some of this stuff, so we'd need to use a COW setup for this pointer, presumably... I guess what happens right now is that things like localName are computed from the nodetype/elementtype enum values? The wrapper field is a *JSObject essentially, which I suppose could conceivably go away if we dictated that the wrapper pointer could be determined by finding the memory position at self - (sizeof(JSObject) - sizeof(JSVal) * MAX_FIXED_SLOTS) when self is the root of a DOM hierarchy. Right. Why would this be limited to roots? What's the self pointer for non-roots? The nagging question I have, I think, is how easy is it to implement a new DOM object in this setup? One reason we're trying to avoid the CC/tracing boilerplate is that it's annoying/confusing to write and error-prone so people new to implementing DOM objects often screw it up, right? What are the constraints on DOM object implementers in the new setup, and how are they enforced? How do they affect the experience of implementing, or modifying the implementation of, a DOM object? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] dev-servo Digest, Vol 17, Issue 18
On 7/25/13 11:27 AM, Leo Meyerovich wrote: Think of it like GC: many little nurseries and an occasional compaction. OK, so movable DOM nodes. That would be interesting to try... especially if we're already doing movable DOM nodes because they're in the GC heap. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] One other note on selector matching
Something else that I forgot to mention during the discussion earlier today: do we need to worry about the subject indicator stuff Selectors 4 is adding? Or is that not an issue for rendering/style for now? The spec discussion is ... unclear. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Meeting notes - further discussion of selected topics from Unanswered questions thread
On 7/15/13 3:05 PM, Josh Matthews wrote: https://github.com/mozilla/servo/wiki/Meeting-2013-07-15 Some comments on the discussion (sorry I couldn't make the meeting, and thank you for the notes!): 1) Mutable prototypes will be supported in SpiderMonkey (and indeed are), but they will likely not be fast (and indeed, they are not). For one thing, they totally defeat the way TI works right now. In practice, we should check how often C++ objects are allocated without setting up their proto chain in Gecko. I bet it's not too often If we get desperate here, we can try to make DOM prototype setup faster in SpiderMonkey. Right now it's slow mostly for dumb reasons. Or are we worrying about the memory used by the prototypes? 2) We can modify Spidermonkey as needed, and should, but we also want to avoid biting off more than we can chew (e.g. replacing TI wholesale is probably not something that should be on the blocking path to servo). Especially given that the JS team doesn't have spare cycles. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Unanswered questions from a QA about Servo
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 wrapped and unwrapped DOM nodes, I don't see how we
can have no cycles between the two...
3. Use the JS GC for wrapped objects and unique ownership coupled with
weak pointers for non-wrapped objects. In other words, there is a single
strong owner for each node and all other pointers from Rust to the DOM
are weak. (For example, event targets for queued events would be weak
and if the DOM node dies then the event is dropped.)
I rather doubt this is web-compatible... Consider this simple testcase:
(function foo() {
var img = new Image();
img.addEventListener(load, function(e) { window.x = e; });
img.src = whatever;
})();
The event needs to fire. Futhermore, once it's fired window.x.target
needs to be the DOM node... I suppose the DOM event could trace the DOM
node and the image load could be the unique strong owner, but this
seems fragile...
Option 4 is to go with a GC and CC setup and refcounting on the Rust
side, I guess.
-Boris
___
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Unanswered questions from a QA about Servo
On 7/12/13 10:09 PM, Boris Zbarsky wrote: Option 4 is to go with a GC and CC setup and refcounting on the Rust side, I guess. Though the developer experience of CC is not that great, to be honest. What would implenentation of a DOM object that ends up not fitting in 18 64-bit words look like? I assume the compiler would prevent people doing that by accident, right? Also, I assume that when we say DOM object here we mean not a Node but anything reflected into JS? -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Selector matching in Rust
On 6/28/13 4:58 PM, Simon Sapin wrote: * Different rules can use the same selector. Map unique selectors each to a list of rules, so that identical selectors do not need to be matched more than once. That's an interesting idea; it's worth measuring how often this is useful in practice * For each element in the document, possibly in parallel, find matching selectors. The maps defined above allow rejecting quickly most selectors. The end goal is to end up with a (sorted in specificity order!) list of matching rules, not just the list of matching selectors. How to get there is an interesting question. * There is a bloom filter for descendant combinators. I don’t understand exactly how this works yet, but more code reading should fix that. Reading https://bugzilla.mozilla.org/show_bug.cgi?id=705877 (note comment 0, comment 5), might be simpler, or at least worth doing before reading code. Did I miss something important? We need to think about what the in-memory representation of selectors will be. We're not happy with Gecko's, in particular: it's pointer-chasey and malloc-happy. This can be rejiggered as needed at a later point, probably, depending on what exactly we're using selectors for. Perhaps more tricky is dynamic changes (in stylesheets, in DOM tree, etc.) Should we consider as soon as now how to make them fast in selector matching? If you haven't read https://wiki.mozilla.org/Servo/StyleUpdateOnDOMChange you probably should... In particular, one of the hard bits with parallel selector matching is that selector matching needs to store deoptimization flags on DOM nodes or something attached to them or something to make dynamic changes fast. So to that extent, you need to consider dynamic changes when designing selector matching. Would it help to have a video / whiteboard discussion of all this? I want to say yes, but we should have a plan for what we want to discuss, so we don't get sidetracked on things like the selector in-memory representation, say... -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On 2/14/13 5:33 PM, Brian Anderson wrote: * FFI stack switching - https://github.com/mozilla/servo/issues/278 * FFI virtual calls - https://github.com/mozilla/servo/issues/278 * DOM representation - https://github.com/mozilla/servo/issues/280 * string representation - https://github.com/mozilla/servo/issues/282 * optimizing layout requests - https://github.com/mozilla/servo/issues/283 3 of those are on the list for the new milestone. The string and layout issues are not. Do you think it is appropriate to make either of those part of the milestones for this year? Are there other critical performance questions I'm forgetting? In terms of DOM bindings, no, I don't think so. I do think we should get our string story straight sooner rather than later, or at least make sure we don't start depending too heavily on it being a particular way.. I'd really hope we can do that this year. A far as optimizing layout requests, I think that's more tuning that will need to happen sometime, but isn't urgent as long as we can demonstrate that we _can_ do it fast enough in a microbenchmark. I hope this helps ease your mind somewhat Oh, my mind was at ease already, more or less, on the DOM bits. We can solve it; it's just a matter of timeframe... I'm more worried about strings and cross-task communication. For your reference, some of the performance issues you've raised previously are already impacting Rust's design. Most significantly the [FFI] is in the process of being redesigned to support servo's use case. Also, the upcoming [scheduler] redesign should give us more opportunities to experiment with optimizations relevant to servo. That's really good to hear! -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] More planning
On 2/13/13 11:19 PM, Patrick Walton wrote: Servo now ships a known-working version of Rust, so it should be easier to build. Ah, excellent. I should try again! Fixing this will require the scheduler rewrite that brson is currently working on. As per the current plan for the rewrite, content will be able to atomically steal the sleeping layout task and context switch into it if it is sleeping, which should be very fast; overhead over a function call is one atomic operation plus some more register saves/restores. 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 on the scheduler rewrite? Maybe for a performance test we could just have the layout spin in a separate thread. Communication is lock-free as long as the layout task is awake at the time of the send. This may not be as fast as the sleeping case under the scheduler rewrite, however, because it increases the multi-CPU bus traffic. Not as fast might be ok if we measure it that way and it's still fast enough. The thing to watch out for is accidentally measuring unrealistically fast things here. A simple frontend to establish the multi-process model. The rationale is that getting multi-process working early is better than putting it off to avoid the situation we are in with Gecko. Gotcha. I plan to write up my thoughts more on the wiki tomorrow, but I am currently leaning toward not using copy-on-write and instead just having the DOM objects' contents be immutable while layout is running. Hmm. This loses us a lot of the quickly return to the event loop and page script benefit we're ideally aiming for, I think. It also makes doing any sort of speculative layout much more problematic, right? Why the change of heart here? Or should I just wait for your writeup on the wiki which will cover that? This is basically the way Gecko and WebKit do it Well ... yes. And it's a serious source of user-visible and script-visible jank in both. so this reduces the single-threaded performance risk. Not sure what this means. For now JS will just block if it wants to mutate the DOM while layout is running. If we want JS to be able to mutate the DOM while layout is running without blocking, then we could add some sort of change queue or journal later on top of this design. Hmm. How does _get_ performance on a modified DOM look in this approach? Just saying we can add some sort of thing is ... not quite enough. For this stuff the details really matter. I think we should just ignore the fact that Rust cannot currently inherit traits from structs for now OK. How temporary is for now? and implement the DOM object methods that have to be virtual using unsafe Rust code. You mean non-virtual, right? Basically we can just embed a vtable full of extern fns into the structs that represent the DOM and manually cast to obtain the self pointer. How is this not virtual dispatch? I feel like I'm missing something, but I can't tell whether it's my lack of Rust knowledge or something else. The endgame I would like to see for our DOM representation is that the DOM impl can write some sort of (presumably very simple) firstChild getter in safe Rust code and the binding can be generated in such a way that the compiler will inline the getter into the binding when all is said and done. (Inheritance of traits from structs is the missing feature that we would need in Rust to make this safe.) Later we can add that feature to Rust and make it safe. But for now this would give us the right performance model: a struct with flat fields, supporting a combination of nonvirtual and virtual methods. That seems ok for basic performance sanity testing, sure. Not so great for actual implementation. Do we have any ETA on inheritance of traits from structs? This also seems like a higher priority than floats. Regarding stack switching, I have a proposal that has achieved tentative consensus on the Rust team that should allow us to remove the stack switching burden from the DOM task entirely for calls from Rust into the JS engine and vice versa. So we should be good there. Sounds great. It needs to be implemented, of course. This, too seems like a higher priority than floats. ;) -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] Servo license
I vaguely recall some discussion on this going by. If people haven't already seen it, I recommend reading https://groups.google.com/forum/?fromgroups=#!topic/mozilla.dev.planning/CrwdQkJRfEM -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
[dev-servo] DOM bindings thoughts
jdm mentioned that he's working on DOM bindings again, so I wanted to write down the things that we've run into as performance or usability gotchas in Gecko bindings so far. Performance: 1) For interface types, one needs a very fast way to unwrap them to some sort of object you can call methods on. In Gecko this is done by ensuring that all the classes representing DOM prototypes for a particular object have the same pointer so you can reinterpret_cast between them (for example, the EventTarget*, Node*, Element*, HTMLElement*, and HTMLDivElement* for an HTML div all have the same value). Then that one pointer can be stored in the JS object, and all you have to check at runtime is that the the cast is safe. What do we plan to do for the memory layout of DOM objects, and how do we plan to make it work with binding code? 2) For sequence in params for WebGL, you really want to stack-allocate the array for short arrays. Passing very short sequences for uniform*fv is common, and heap-allocation is expensive. 3) Strings are a major pain point. You want to be able to share strings between SpiderMonkey and your DOM stuff for return values. You also want some sort of JSString* cache, though this is not fundamental to the design and can be tacked on easily, I think. I know we have plans to sorta using JSString* internally kinda; the might be nice. 4) It helps a huge amount to be able to inline the implementation into the binding or at least make it a non-virtual function call. Virtual function calls are terrible not just because of the indirection but also because of fairly common cache misses on the vtable lookup. Usability: 1) Ownership model (though at this point CC is getting more usable). In Gecko this is exacerbated by there being different models on main thread and in workers; let's please avoid that. 2) You want the same representation for arguments of both callback interfaces and natively implemented interfaces. Otherwise you get annoying impedance mismatches. We're working around those in Gecko with evil conversion operators, since you can do that in C++, but it's slightly suboptimal. The fact that we don't have to worry about ref vs pointer vs NonNullT in Rust will help here. But that doesn't necessarily help with the fallible/infallible array mess. 3) The combination of the two, where you can't necessarily use the same type for Node in both Node and sequenceNode arguments because for the former you want to be fast while for the latter you have to keep the Nodes in the sequence alive. 4) Dictionary return arguments are a bit of a pain point. See https://bugzilla.mozilla.org/show_bug.cgi?id=817194 -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
Re: [dev-servo] Handling adoptNode
On 10/24/12 7:04 PM, Robert O'Callahan wrote: Couldn't we replace the original with a proxy that forwards to the new object? For access from JS that's exactly what we'll do. The question is what happens for access from Rust. -Boris ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
