Q1 OKRs - Wednesday, January 7, 2015

Attendees: benjhayden, cbiesinger, dsinclair, eae, jchaffraix, nduca, szager, skobes

... Pleasantries, going over the list of proposed OKRs ...

[ Discussing the proposed "Have ten layout benchmarks with less than 1% variation between runs" OKR ]

<benjhayden> For the benchmark OKR are you referring to to descriptive benchmarks?

<eae> Not necessarily, the goal is to have reliable benchmarks to guide our work. Short term that likely means silk-style measuring layout times.

<jchaffraix> We do want to move to descriptive benchmarks (new type of benchmark using recipes) eventually.

[ Discussing the proposed "Improve two benchmarks by 10%" OKR ]

<cbiesinger> How will we choose which tests to improve by 10%?

<jchaffraix> Any of the tests really.

<eae> Will be guided by our findings when adding benchmarks and doing profiling.

<cbiesinger> We should make the objective more precise, what kind of benchmark?

<nduca> Make it two key_silk cases

[ Discussing the proposed "Support subpixel layout during animation" OKR ]

<skobes> What is involved with subpixel layout during animation?

<eae> Today we snap to CSS pixels during layout, which ensures crisp rendering, but during animations this causes animations to move on full pixel boundaries which isn't ideal.

<nduca> It's all about enabling natural animations.. without that layout animations looks bad.

<eae> ...really bad.

<dsinclair> Do we have any idea how hard it will be?

<eae> Technically all we need to do is not pixel-snap during animations but doing that without complicating the code and introducing a separate code path for animations could be tricky.

<dsinclair> We don't want to add "if (animation)" checks everywhere.

[ Discussing the proposed "Move line layout to LayoutUnits" OKR ]

<eae> How is the work to move line layout to LayoutUnits coming along, is finishing it in Q1 a realistic goal?

<benjhayden> Should be doable, making good progress. Stefan has started helping out.

<dsinclair> A lot of it is figuring out rounding errors and burning down the list of issues.

[ Discussing the proposed "Prototype and propose Measure API" OKR ]

<nduca> Is the Measure API OKR about Element.measure

<eae> It is really too early to tell. We don't know Element.measure is the right API yet, hence the need for a prototype.

<jchaffraix> The idea is to create a prototype, possibly based on Element.measure, implement it and see if it solves the problem.

<nduca> So basically talk to Tab, spec the API and send out an "Intent to Implement"? It doesn't have to be faster, it just needs to be separate from layout.

<eae> An intent to implement might be premature, we need to figure out if we can support the proposed API first and if it actually works as expected.

<nduca> We have a lot of requests for this and it is really important. Nothing is sure or has been decided but we need to do something in the space.

<eae> Julien and I talked about it earlier and think it is important to have a prototype and have someone from Docs or another client experiment with it to make sure it fits their use cases.

<nduca> This isn't for Docs or desktop apps, they already have working solutions and use native apps on android. It is more about animations between layout states.

<nduca> Check with [ internal team, redacted ]

<nduca> This is important for people doing transition animations from one layout to another. They have to do the new layout and measure it, doing that today requires jiggling and hacks when all they need to know is the final state. We don't have to make it faster, just needs to support doing the measurements without invalidating the universe.

[ internal discussion, redacted ]

<eae> If that is the end goal there are other ways we could approach it.

<jchaffraix> Let's change the OKR to "Create a prototype and write-up of lessons learned"

[ Discussing the proposed "Finish root layer scrolling" OKR ]

<eae> Is finishing root layer scrolling this quarter a realistic goal?

<skobes> Making good progress, should be able to finish this quarter.

[ Discussing the proposed ClusterFuzz OKRs ]

<skobes> How many clusterfizz asserts are you seeing now?

<cbiesinger> About 4 pages, burning down, not sure if more will surface. Some are on the chrome side and out of scope but there are a good number of them.

<cbiesinger> Actually, make that 18 pages, 10 per page...

<eae> The OKR might be a bit too optimistic then, just triaging that many will take quite a while.

<dsinclair> Triage and fix 50%?

<cbiesinger> More reasonable.

<dsinclair> Can we do the auto triage?

<cbiesinger> Abhishek said the ClusterFuzz team would help with that.

<jchaffraix> How about team warden specific OKRs?

<eae> We have 'scrolling' and 'line layout'. Do we need more?

<julien> Ok. What other warden tasks are ongoing?

<dsinclair> Fullscreen and single item list selectbox (also on android) are ongoing tasks in that realm.

<nduca> Should we have a code health objective that captures what you are doing Dan?

<nduca> Next quarter the the boundary between layout and style needs to be better defined, we should help with that.

<julien> By defining an API?

<nduca> Code health and new features are separate concerns. We can make our lives and the life of the style team easier by being healthier, paying down technical debt. Making people faster is good investment.

<dsinclair> Agreed.

[ Discussing position sticky ]

<eae> Gmail, docs doesn't see it as top priority.

<nduca> Mobile first matters for this, apps do not... ads, mobile apps matters.

<eae> Seems to have fizzled out from a year ago, is it still relevant? Do we have anyone asking for it?

<nduca> We can likely punt it for bit longer but it will come up. We might have to bite the bullet and do it eventually.

<nduca> The extensible web approach (layout hooks) might be better.

[ internal discussion, redacted ]

<eae> Agree that solving the larger problem would be better. Let's revisit position sticky in Q2.

<dsinclair> Wouldn't layout hooks disable the compositor?

<nduca> By delegating to js we would lose compositor hotness.

<skobes> Already moving in that direction with delayed scrolling, other concepts. Certain features disables the compositor wins. Trade-offs.

[ Discussing the proposed "Improve two tests by 10%" OKR ]

<skobes> Who would be responsible for the 10% perf wins?

<benjhayden> Would be everyone? I have some things that would imrpove performance. I think Emil can deliver some wins though the text optimization work. Text shows up prominently in profiling runs.

<skobes> Is that simple vs complex text?

<eae> not really, in the short term. Long term there are a lot of things we can do to speed up complex text and (eventually) move to one text path. In the short term there is a lot of room for improvement by simplifying things and avoiding unnecessary work.

<eae> Some of Ben's work, like short-circuiting the float handling in layout, could have a big perf impact.

<nduca> Everyone should try.

<eae> Agreed, with new the new tests it is easier to track.

<nduca> How about having a weekly meeting to keep on track?

<dsinclair> We have one already, Mondays at 11. Re-purposed the Team Warden stand-up.