Skip to content

Meeting 2014 10 20

Jump to bottom
jdm edited this page Oct 20, 2014 · 1 revision

Servo Meeting 2014-10-20

Reminder

Please update your status at: http://benjamin.smedbergs.us/weekly-updates.fcgi/

Agenda

Attending

  • ms2ger, larsberg, mbrubeck, cgaebel, jdm, pcwalton, abinader, Azita

Agenda items for the workweek

  • larsberg: We have a big list of items. We've been asked by Andreas and others to come up with a 2015 plan, so I'd like to sit down as a team and work out a product plan and priorities for the year. I've been talking with zwarich and mrobinson about graphics stuff; is there anything else that should be on this list but isn't? If anything comes up, put it on the Etherpad or talk to me and Jack. Also let us know if we need anyone from Gecko present like dbaron.

  • zwarich: I'm sure you already have this in mind, but November 4th is a research org meeting with the CEO, so we should schedule around that.

  • larsberg: I'm giving a brownbag on Air Mozilla at 11am that day. (Monthly brownbags are replacing the monthly research staff presentations.)

  • zwarich: The CEO Q&A is from 10:30 to 11am. Not sure if it's relevant for all of us.

  • larsberg: Okay, thanks for the heads-up.

  • mbrubeck: Meet with Android platform people in December?

  • larsberg: We should coordinate that early.

  • mbrubeck: Jim Chen did the keyboard support in Fennec.

Infrastructure

  • cgaebel: Trivial patch removing debugging output is not landing because of WPT failures. How do I fix this?
  • jdm: We have two problems. One is we turned on a patch that distinguishes chrashes from timeouts. Second is intermittent failures due to race between XMLHttpRequest events. There's a patch open to fix the second, but it's really big (so not a straight r+). Hopefully it'll go away once that lands.
  • cgaebel: Nothing can land until that patch lands! My patch doesn't change anything!
  • jdm: Intermittent is painful - keep retrying for now.
  • pcwalton: Rust is currently worse because it takes so long.
  • zwarich: It's the same, but 3 hours for the turnaround.
  • larsberg: How did we land it in the first place?
  • jdm: It was originally counting as a timeout, despite being crash OR timeout.
  • mbrubeck: So, we're getting things that sometimes timeout but sometimes crash?
  • jdm: Yes. Other option is to disable the differentiation for now. I'd be open to that.
  • mbrubeck: Last time we had bad intermittent failures, I ended up manually merging when I got "a set of green successes"
  • pcwalton: That makes sense.
  • larsberg: How about we revert differentiation, and then enable it when the XHR fix lands.
  • manish: Or disable XHR tests.
  • jdm: Let's do that.
  • larsberg: Yes.

Inversion of control

  • pcwalton: I know mbrubeck has discussed this. I have a branch that redoes the way events work. It might overlap with your work? Instead of polling for events, the embedder pushes events into the compositor. You mentioned this was necessary for embedding?
  • mbrubeck: Event loop was next on my TODO list, so that is perfect.
  • pcwalton: Working on frame-perfect resizing & scrolling and needed to do this inversion to get it working. I also added a refresh driver. Patch should come pretty soon. I'm very excited about how smooth it is - much better than Firefox or Chrome! Expect patches coming soon that redo all of that. Did have to add some horrible hacks to glfw to make resize work to handle some issues with Cocoa on OSX.
  • pcwalton: I also have parallel painting. We should discuss (larsberg) what happens on Linux. Disabled it on GPU rendering, but it still goes to a separate thread so I may need to turn it off harder.
  • larsberg: We used to filter out and drop redundant resize messages if we were in the middle of a resize. Did that change?
  • pcwalton: Yes and no. I didn't adjust what happens when you get a resize event. However, the overall picture has fundamentally changed. Cocoa does this annoying thing where it spawns a nested event loop on a resize... well, worse, it actually just bombards you with resizes. During that time your window is not receiving any events at all. I had to hack glfw-rs to allow this work. I don't know if Linux has similar issues, or how resizing works on Windows. Basically what happens is that during a resize on Mac, we start blocking the compositor thread on all painting, because there is no other way to get the paint messages, because you're stuck in this nested event loop sort-of-thing.
  • zwarich: WebKit on OS X is able to do synchronous resize that is pretty good, better than Firefox. I'm not sure how it works or if we're able to do it. On a page where layout is taking too long, it falls back to asynchronous.
  • pcwalton: We could do that by adding a timeout. That's totally doable.
  • zwarich: I might take a look at it if the code is in WebKit.
  • pcwalton: I briefly disassembled NSWindowResize and took a look at it. I didn't see any way to get around the nested event loop behavior.

Synchronous script loading

  • mbrubeck: Have a PR almost ready to land that changes the way we load scripts during parsing. Instead of fetching on a separate task, we fetch them synchronously and execute them immediately. This brings us closer to the interoperable, spec'd behavior. May make a difference on some of our measurements (since it changes on page load, especially for real-world test pages). Not sure if it'll show up a lot in things we're benchmarking, but be aware! As a follow-up, we can implement the async and defer attributes for the script element, which will let pages opt-in to that behavior.

Document load tracking

  • jdm: I have a PR up for document load tracking, which helps fire it at the right time, instead of just guessing and hoping. I need a reviewer!
  • larsberg: only jgraham?
  • jdm: Someone with strong DOM knowledge...
  • Ms2ger: I want hsivonen to be the reviewer...
Clone this wiki locally