Skip to content

Meeting 2015 05 11

Jump to bottom
Lars Bergstrom edited this page May 12, 2015 · 1 revision

Agenda items

Attending

  • gw, jdm, larsberg, samsung, pcwalton, bbirtles, savago, brson, kmc

Animations

  • bbirtles: Wanted to reach out about the JS animations API and comes out of the extensible web platform idea. Can get animation objects that represent the CSS animations and transitions. In gecko, taking existing implementation of CSS animations and transitions and retrofitting the API onto it. In gecko, implemented them separately. Part of the work is making them use the same animation objects and exposing those objects to script. Using it in gecko for the animation devtools, which is how you can control and read them.
  • bbirtles: next part is making them run from scripts. So, I heard you're looking at animations in Servo. One idea is not to start with CSS animations and transitions, but start with the API itself since it's the lower layer and CSS animations and transitions build on top of it. That's one way you can do it instead. Then the CSS animations and transitions generate them. The main difficulty is that the web animations API is still changing. Some parts are still shifting, but some parts are stable. So it might not appeal to you if you're reworking stuff. But could at least make CSS animations and transitions use the same primitives under the hood so you can just expose them to script - would be a wise move.
  • bbirtles: In the compositor on gecko, we're using the same objects, but not on the main thread for animations and transitions. I dunno if there's anything in particular that you would be interested in talking about with them from Gecko?
  • pcwalton: I can talk about how it relates to Servo. We have CSS transitions but not animations. It's implemented with a generic infrastructure for all animation-related things called "animation." The issue with doing Web Animations or everything in terms of them is that everything runs off the main thread - even those that require reflows. There is never any communication that needs to happen between script and layout. The animations just run with their own timers. I haven't looked at the Web Animations spec too much to know if it's compatible. One thing that this wouldn't work with is creating a DOM object for every CSS animation. We can't do it because the CSS animations live in a different thread from the rest of the DOM.
  • pcwalton: We are going to need something - we can't express everything in terms of main thread DOM APIs. Can use off-main thread infra and try to use that for all of CSS transitions, CSS animations, and WebAnimations - that makes a lot of sense. Creating DOM objects for all of them we probably can't do because they all run off main thread.
  • bbirtles: I don't understand the architecture so I can't comment. We do make DOM objects for the things - like for SVG and proxies. It's fine for animations to run off the main thread. The DOM objects are on a different thread and when you query the timing we calculate it then. It's a different way to do that. Lots of work to reconcile our animations and transitions code and we're doing it all again with our script-generated animations. As long as you have the three different types of animations in line, that's probably all you need to keep in mind.
  • pcwalton: I wrote it expecting that I was expand it to CSS animations and web animations as well. It's kind of a generic framework with timers, hooked into the refresh driver to sync with the compositor, schedules reflows even when the main thread is busy and things like that. I think we would want to reuse it for CSS animations because it was a lot of pain to hook up and I don't want to do it again. Have to look at web animations to see how well it fits in, but our framework is pretty simple right now and just supports transitions and reflows even when it doesn't have to. We do want to be smarter eventually. We will probably want to use Web Animations as well.
  • bbirtles: Sounds like a good place. One recent architectural change is making animations a two-phase things: separating timing and triggering the style changes separately. Bugs around calculating the timing twice in a single tick. So we're making timing happen once in each frame and then the animated style values can be updated multiple times on the frame.
  • pcwalton: Servo is OK there. We batch all the timing updates and perform them once. There's something to consider with the special path through style lookups. The ones for animation don't happen through the same path through the DOM (because of off-main thread access). That's how we keep the animations off the main thread. One thing we may have to be concerned about is multiple iframes with synchronized iframes. Because iframes are in separate layout threads (and JS runtimes where cross-domain/sandboxed), we may need to do something to get cross-iframe sync working. We have none right now and have artifacts. Not clear how much transactional stuff we want to do for that.
  • bbirtles: Sounds like a good handle on it; the web animations stuff is tough.
  • pcwalton: I'll look at the spec soon!
  • bbirtles: Any feedback would be great! It's written between gecko and blink engineers, so it does assume a model. If you could help provide feedback on it, that would help.
  • pcwalton: off main thread animations do cause some issues. We may have to stop animations if there's a script query of the event loop so that script doesn't see different values of something like offsetLeft if it's animated because servo could have multiple values where other browsers would not. It would be good to know what other hazards there are.
  • bbirtles: We do animation twice (main thread and compositor) for that reason. Glad to see you've thought about it and glad to hear any feedback, especially about things in the spec.
  • pcwalton: Do you know what CSS animations are mainly used for on the web? I've seen the chrome usage counts, but it's hard to know what we should be focused on.
  • bbirtles: I don't have the data. Chrome did some usecounters on which properties get animated and that opacity was #1 (not transform). Probably transitions more than animations.
  • pcwalton: Yes, I'm just wondering what people use animations for - sites don't break though we haven't implemented them yet.
  • bbirtles: They're used a lot, but it's hard to know what the specific use case is. Animations tend to be more presentational than state-oriented. Good question; I don't have the data.
  • pcwalton: Thanks for your time / advice!

PR tagging

  • larsberg: jdm and I will be assigning reviewers to PRs. This makes it easier to query who is responsible for reviewing a given PR, and the tags make it clear what the next step is. This doesn't mean take the PR over!

Whistler

  • larsberg: etherpad tracks where/agenda/etc. Welcome to attend anything interesting. Other idea being kicked around is not just nightime bash on sessions, but actually having real training. Going through exercises on Rust, learning how to contribute to Servo. Fleshing it out right now - gauging how much to put together, how much interest there is. So far, the answer is LOTS. Going to move forward next week and figure out space, do we need help, etc. Niko wants to have Rust people involved in the training. Any suggestions around content that would be applicable to this crowd would be welcome.

Rust in Gecko

  • larsberg: With almost no effort from us, both the network team and the media team have been pushing forward on getting Rust integrated into the Gecko build system. There are now configure hooks, it sets variables, you can add source files... It's moving along! Anybody who wants to be involved, let me know. Helping gecko is always a good thing.

Piston image

  • kmc: I've been working on switching over to the image library. The integration isn't hard, but the library seems to have a lot of bugs where it will panic or overflow integers. This is without even looking for pathological testcases. Should I keep pursuing this? The developers have been pretty responsive, but the JPEG decoder is unmaintained for example, so we would likely need to take it over. We could also switch over JPEG to use a native library.
  • mbrubeck: Even the PNG decoder isn't well-tested. They broke the output badly recently.
  • kmc: Luckily we don't care about output, and still use libpng for that.
  • mbrubeck: If we could fix enough bugs that we could handle images in the wild, it probably wouldn't be too hard to build up a community-supported testsuite.
  • kmc: I could put something like that together. I've been using AFL recently, and it can look for panics as well as segfaults. I will see if there's something we could do to make it easier for other people to hunt them down.
  • pcwalton: I'm wary of biting off more than we could chew to maintain an industrial decoder. If we get more resources (or community support) then we could take that as it comes. Right now I'm more comfortable using the devil we know (libjpeg-turbo).
  • kmc: It's clear that switching to piston would be a win for security, but if it makes Servo crash in the wild, it doesn't help usability. I've been encountering the big gap between gamedev uses of image decoders vs. the real world. We don't have resources to maintain a production decoder ourselves. If you think there's some community you think I should talk to...

rustup block

  • larsberg: We're still blocked on a crash in the Rust upgrade, where it looks like a value is being dropped too early, or something's wrong in the generated code. We should look into that, especially since zmike is seeing a similar-looking issue in different code.
Clone this wiki locally