One of the things I’ve been working on since I got back from Taipei has been helping with the implementation of vertical-text in Gecko which WEBVTT needs to support. The small way in which I helped out was to implement the “writing-mode” property in the style system. Basically this is just getting the Gecko CSS parser/scanner to understand the new property and be able to process it correctly. This was fairly easy to implement due to Daniel Holbert (:dholbert) giving me an awesome walkthrough of the things that would need to change in order for this to work and also an example bug where he did a similar thing. So after half a day doing the initial code and a few rounds of review it landed in the tree and we’re now one step closer to vertical text!
If you’d like to learn more about how the style system works you can head over to the style section of the Gecko overview page which also has a lot of really good information on how Gecko works in general. I won’t duplicate information here, but I will talk about a couple of the things I found interesting in the style system.
- CSS property values are stored in a computed form and there are translation mechanisms to go back and forth between the two.
- The computed values of CSS properties live in structs, namely nsStyleStructs, and CSS properties that tend to be set together live in the same struct. For example — when a user sets the font-family property they are likely to also set the font-size, font-weight, etc, so storing the computed values of these properties together makes sense.
- Single instances of nsStyleStructs, i.e. one set of related properties, are shared across many different DOM nodes as DOM nodes are more likely to share one set of CSS properties then they are to have different sets of properties. For example, the vast majority of times that a page sets font properties the entire page will share these properties. This cuts down on memory usage. These structs are immutable and when the same CSS property needs to be set differently on another set of DOM nodes a new struct will be created for the new set of properties.
- Each nsStyleStruct has a CalcDifference() function that gives hints to Gecko about when it needs to update the rendering of the page based on the CSS properties changing, i.e. if it needs to reconstruct the frame or the text needs to be reflowed, etc.
In the future I’m hoping to help with more layout things. Hopefully, I can do the same kind of bug for the “text-orientation” CSS property, which is also needed for vertical text. I haven’t started as of yet as it’s still kind of up in the air in the spec. Right now I’ve also started work on another easy bug to reorganize the reftests in layout/reftest/form. Hopefully, I can get that done sometime next week. We’ll need reftests for WEBVTT as well so this will be a good bug where I can learn about them.
So I’m back home now. The flight home was a bit shorter, about two hours, thankfully. Interestingly enough I feel more jet lagged now that I’m home then I was in Taiwan. I’ve heard that going east is worse then going west, so that might be the case for me right now. The rest of the rendering week, after I blogged last Tuesday, was just as awesome as the first part.
How Gecko Does X
I got to sit in on a lot more talks about “How Gecko does X” — like how the graphics engine works, how the layout system works, and my favourite in particular, how cycle collection works. Kyle Huey did an excellent job explaining how the Gecko cycle collector works. He gave us this paper as forward reading about it (it’s a little dense, but definitely worth reading). I’ll try to do a blog post in the future on what I learned/will learn about it.
David Baron and Adam Roach also gave an awesome talk on how the W3C and IETF work. WEBVTT is my first major exposure to open specifications that I’ve had and so I’ve been interested in all the hows/whats/whys of open specifications and the politics behind them.
Initial WEBVTT Support
It wasn’t all fun and games over in Taiwan though. We were also doing a lot of work. We finally got bug 833385 landed near to the end of the week. This means that we have support for all the new DOM elements that WEBVTT introduces such as: HTMLTrackElement, TextTrack, TextTrackList, TextTrackCue, and TextTrackCueList. We ran into a random inexplicable bug when we were doing full tries on the code, just before landing it. Ralph and I went to work debugging it (had to use an ASAN build) and we ended up discovering that it happened in a very rare situation where the cycle collector nulls out the HTMLMediaElement’s TextTrackList member while the HTMLMediaElement is still alive. This results in a situation where HTMLMediaElement::FireTimeUpdate() is called just before it is about to be deleted and since we weren’t doing null checks on the call to TextTrackList::Update() we would crash. After we got that fixed we were all green.
That leaves just bug 833382 left before we get initial support for WEBVTT. It was going well last week and we got an r+ from Chris Pearce. Now we just need an r+ from Boris and we should be good to go. It might take a few more rounds of review before that happens, but I’m optimistic we will be able to get this landed within a week or so.
One of the major problems I was having in Taiwan was trying to get a clean diff for 833382. The problem centered around the fact that up until now, mainly in my previous open-source class, we decided to use a git branch as a main point of ‘integration’. We’ve all been working off this branch for a while. The history of this branch has been so ridiculous and the code necessary for 833382 depends on so many other parts of the code that have been touched by, well everyone, that it was pretty much impossible for me to do a clean diff or even get a good rebase. To rebase this beast I would have had to go through 150+ commits, each having merge conflicts… So I ended up just making a clean branch off master and manually moving all the code that I needed over to the new branch and doing a diff like that. I’ll probably be staying away from these kinds of ‘integration’ branches in the future in order to ensure that my repo history can be more linear. Easier to get diffs that way.
The other thing I’ve been dealing with in the last few days is some code we landed back in February that was spotted to not be up to par by Boris. The issue is with some of the CSS selectors that we are using to style WEBVTT text — namely, we are using slow CSS selectors which is bad. This is the first that I’ve heard about some CSS selectors being slower than others, although that’s not suprising as I’m not super-super knowledgeable about CSS. Mozilla even has a page devoted to this that you can check out here. Ralph and I put together a patch yesterday to deal with this which will land today most likely. I’ll have to update 833382 to reflect those changes today as well.
CSS Parser Hacking
I also sat in on the vertical-text layout meeting as it is of particular interest to WEBVTT. WEBVTT requires the ability to have vertical-text and so far in Gecko we don’t have this. Apparently vertical-text has been kind of a thorn in the side of the layout team for a long time as it’s been particularly hard to implement. However, there is a major push now to get it done, so that’s great. In accordance with this Daniel Holbert asked me if I wanted to do some stuff for vertical-text in the CSS parser, I accepted and got my first layout bug! So I’ll be hacking around in the CSS parser and layout section of Gecko more in the future, hopefully.
Dave also told me the other day that he’s figured out an area of WebMaker that I can start contributing to, so I’m excited about that. I’ll be starting in about two weeks on this. I’ll most likely be splitting my time like 70/30 or something like that for WEBVTT and WebMaker. We talked briefly about it and so my understanding isn’t 100%, but what I got from our talk is that I will be implementing a kind of wrapper around an HTML5 video element that will allow Popcorn Maker to be able to work with it. From my understanding Popcorn Maker works with many different video formats/sources and so it needs a uniform interface to work with all these different videos. That’s where the wrapper comes in. It allows Popcorn Maker to work with many different video formats and sources without worrying about the particulars. However, all this might be completely wrong as I might have misunderstood some things from our brief conversation… So don’t take my word for it! At any rate I’ll do another blog post about it when I get more information.
Until next time.