Agenda items

Potential User Agent changes (larsberg)
- Add linux platform, support overrides for broken sites
Android woes - apk builder, android glue, glutin (larsberg)

Profiling on ARM? (pcwalton)

Attending

brson, laleh, larsberg, mbrubeck, mrobinson, pcwalton, manish, gw,

Last week

Team updates: http://benjamin.smedbergs.us/weekly-updates.fcgi/project/servo

User agent

larsberg: As you may have noticed, we landed an actual (non-empty!) User-Agent string for Servo. gw just landed some code that makes it easier to test the Android string on desktop for debugging. I need to fix the string on Linux, and we've already found a situation where we need to munge the string to get around badly-behave UA sniffing sites.
gw: The Enyo.js code sniffs for Android user-agents, and has some weird code that breaks our scrolling code.
larsberg: Too bad that landed right as we were trying to prepare demos.
pcwalton: I've noticed some sites will start sending us flexbox, in particular www.google.com, since they think we're Firefox and can handle it. In general sites that think we're Firefox might expect more from us.

Android

larsberg: We're not in a great state on Android. I'm moving us back to a model where most of the APK generation stuff is in-tree. That should make it easier to debug and play with. One of the holes we have is that right now there's "native glue" that wraps the Android framework, then there's Glutin on top of that, then there's Servo. For almost every new event we want to pass through, there's a lot of threading of data through these layers. We can do that, but will it be upstreamable?
gw: It's only a hunch at this stage, but my hunch is that using an alternative like FreeGLUT will probably be even more work. My guess would be that whatever we do is a solution we can probably upstream, or if necessary maintain ourselves without too much work.
larsberg: My only fear is if we have changes that are too browser-specific.
gw: I think it's worth trying to see how it goes.

Profiling on ARM

pcwalton: We seem to have a lot of issues where things are inexplicably slow on Android for some reason. Android profiling tools make me sad every time I try to use them. My current thinking on this is in a couple of directions. One is to try to do our profiling on ARM "desktop" Linux on dev boards. Those tend to have a more normal Linux stack than Android, fewer proprietary blobs, easier to compile your own kernel. The problem with that is that we don't have a port of Servo to ARM desktop Linux at the moment, at least not one that's officially supported by our Rust snapshots and our dependencies. Another option is looking at Cyanogenmod or something like that, one of the more hacker-friendly forks of Android. I don't know whether that's true.
mbrubeck: I've been using Cyanogenmod on my tablet mainly to have a rooted image.
pcwalton: gdb?
mbrubeck: Haven't used it with servo; did with fennec.
pcwalton: First is just getting gdb working again. We will want profiling, too. Another off-the-wall-suggestion is porting to iOS and Instruments.app.
gw: Another option is to build our own profiling infra. I did that on almost every console title I've shipped. It's not as fine-grained, but it is not a huge amount of work to implement and works on ALL platforms.
gw: https://images.eurogamer.net/articles//a/1/3/4/5/5/3/5/tech4.BMP.jpg
pcwalton: Doesn't Gecko have SPS profiler stuff? I agree that would be useful. Could grow up our -p infrastructure - it's got a lot of what we need for that.
gw: That's what I was wondering. Could we extend the -p and add a mode where the compositor can draw it on-screen? That would probably be 80% of what we need.
pcwalton: We would want network stuff in there somewhere, too. I suspect on Android some of our problems are just due to our network code doing something bad. It's kinda weird because it can be spikey, but we still need to know about it. Beefing up -p infrastructure would be good.
brson: I want to say that if you're creating a profiler infastructure, please figure out how you could share it.
gw: All of the sampling library would be great to have.
brson: Just cargo installing a rust-instrumenter/profiler would help.
mbrubeck: We also have logging, so we don't need it on-screen.
pcwalton: When I've run stuff on android, our startup is incredibly slow and I have no idea why. We can add a lot of instrumentation to our init.
brson: Does servo on android use dynamic libs?
larsberg: Two: servo and spidermonkey.
brson: Maybe paying for relocations? Doesn't fennec use a custom linker?
mbrubeck: Yes. It reads the .so file out of the compressed APK.
pcwalton: Seems like there are other things. It's not just startup speed; it's just hard to know what is causing our load to be so slow.
gw: I found the same thing on the enyo.js demo. Scrolling the list with a few rectangles works great, but it takes nearly a second to repaint and it's inexplicable how/wy it's so slow.
pcwalton: A profiler would fix this instantly, but it's hard to know.
larsberg: I'm planning to do ARM linux this quarter.
pcwalton: So, in the short term, adding more info to -p would help. And if anybody can write up profiling dev tools info there, it would help.
larsberg: I'll try to add them to mach to make that easier.