Agenda items

webrender (gw)
how to handle reftest differences?
depend on css-parser?
shared DL building code?
automated test of items such as angle gradients
ipc-channel use the "fallthrough" implementation on debug builders so we can run tests? (larsberg)
DOM invalidation changes (ajeffrey)

Attending

jack, larsberg, ajeffrey, pcwalton, mbrubeck, gw, edunham, mrobinson, manishearth

gw: have a few reftests that won't match between Webrender and our existing one. In particular, the borders test. How do we want to handle that? Should we have a separate test pass that runs them in that mode?
jack: I thought they run with the same backend when they run...
gw: No, existing borders reftest fails under webrender b/c webrender supports rounded/dotted borders and the existing one doesn't. I think we'll get to a point where we have some that work under one and some the other.
larsberg: For CSS vs. CSS tests, there's already support for multiple possible outputs from the W3C CSS Ref tests
gw: Problem is the image ones...
jack: Let's talk with jgraham. I'll ping him, since he is polar opposite with your hours.

gw: We have our own types right now. Should we pick them up from cssparser instead?
pcwalton: Might make it hard to reuse in Gecko if we do that...
gw: Looking into how to make Servo build Webrender display lists. Might be simpler not to do the conversion steps for the types.
jack: Maybe pull them out of css-parser or put them in a subcrate?
pcwalton: That would ease gecko porting...
gw: Could do that. That's probably the nicest solution, but they'r eautogenerated from the CSS keywords with the properties.mako template. Huge change to how that works.
pcwalton: We had to factor some of it out already when the autogeneration didn't work. Maybe not too difficult? I'm fine with whatever is expedient.
jack: Why should this cause problems? We'll link it in, drop the unused bits, and be fine. Just a problem when we have style and webrender linked into Gecko.
pcwalton: Yeah, if you drop the dead code, it's probably fine. And a long way down the road.
jack: Simon is on Japan time, if you need to ask him anything.

gw: How do we build Webrender vs. normal display lists?
pcwalton: Depends on how different the two types of display lists are. How eagerly are you flattening? Maybe we could drive everything off the WEbrender display lists, though if you start flattening too early, we won't be able to do that. There will have to be two paths for building them then.
gw: I'll talk with mrobinson about it over the next week or two.

gw: How do other engines test these?
pcwalton: Gecko has fuzzy ref tests - n% can be off. Only thing I can think of. Maybe test the display lists? But doesn't help if you're trying to check the painting.
gw: That would have picked up this error.
pcwalton: Can serialize display lists to json (there's a -Z flag for it).
gw: Anything in WPT that does anything like that? Testing serialized display lists?
pcwalton: Not sure - not all browsers even have display lists.
larsberg: I haven't seen anything in there - most of the CSS stuff is just autogenerated from markup.
gw: Prefrence between fuzzy testing and serialized display lists?
pcwalton: Both have advantages and disadvantages. Display lists don't hardcode percentages, but if you want to change how the display list works, you have to figure out what to do with them. Kinda lean towards exact display list, since we could just regnerate everything and that seems less bad. Gecko people have told us that we'll need fuzzy reftests at some point - sorta inevitable.
jack: Having done fuzzy reftests before, I didn't think it was fun.
larsberg: I'm also worried about the fuzzy testing as too tempting as a way to fake-ignore flaky intermittents.

larsberg: I'd like to be able to test on debug. Mind if I use the ipc-channel passthrough since we can't build just ipc-channel in release? Gives us overflow checking.
pcwalton: Fine by me!

ajeffrey: I've been improving DOM HTMLCollection perf. Hard part is cache invalidation, which requires incremental computation... and the question is: should it be push-based or pull-based? This will touch everything. What's the process here for making this decision? Were it Rust, I'd put an RFC in...
larsberg: Generally, the mailing list is the place to have the conversation. You can also have a meeting conversation, but the morning one is where the DOM/content people are.
ajeffrey: Should I write something up on the wiki about the trade-offs, so we have a basis for conversation?
jack: Yes, and feel free to send a link to the mailing list.
ajeffry: Will do.
jack: Also, if you're going to bitrot a bunch of stuff, we try to land the other PRs (especially volunteers' ones) ASAP.
ajeffrey: Current version doesn't make drastic changes. That said, if that's the approach we will use, it's a bit of a hack - just gets caching done with the least effort. Chances are, if we decide to go for versioning, we're going to want to do so to many things, and then we'd break lots of things.
jack: Also, if your PR gets close, larsberg or I can semi-close the tree to land your fix.

jack: It'll do things you don't need to be a reviewer to do - retry, tries, etc. Folks have been complaining about this. Path to get there via bors? Or just make the list of reviewers in bors non-authoritative so they can use bors?
mbrubeck: I think it'd be useful to have a tier of people who can use try but can't r+ code into master.
manish: Pretty easy to add that to homu.
jack: What does rust do?
edunham: We always have reviewers online, so people can just ask in IRC.
jack: If you see somebody ask for a retry / try, please do it.
larsberg: We could have a bot!