I'm Ahmed Elwasefi, a computer engineering student from the German University in Cairo. This year, I was contributing to Chromium as part of Google Summer of Code 2023.
I approached my participation in GSoC differently from the usual process. When I initially decided to contribute to Chromium, I looked through the good-first-bug in Chromium Issue Tracker to find issues to address in order to familiarize myself with the codebase. While browsing through Chromium's issue tracker, I happened to select accessibility-related problems by chance. One of these issues was created by Aaron Leventhal, so I reached out to him to gather more details about the problem and to seek his guidance in resolving it. To cut a long story short, I was impressed by Aaron's exceptional willingness to assist and share his knowledge. At that point, I thought, "Hey Aaron, would you be interested in some collaboration during the summer?" Just like that, we identified a project, I drafted a proposal for it, and submitted my application. Naturally, Aaron became my mentor for the project.
Chromium's accessibility code is used in both Chrome and Edge. Its main purpose is to enable users of assistive technology software such as screen readers to access the web. In most cases, the code is not needed, and unless platform accessibility APIs are requested, the code remains dormant in order to avoid extra overhead. Unfortunately, enabling it can drastically affect the loading times, general performance or jank of web applications, memory usage, battery life, and crash frequency for end users. Many users get this code enabled without realizing it, because a variety of utilities such as password managers, anti virus software and multi-monitor management utilities request platform accessibility APIs. Ultimately, the accessibility code degrades the web browsing experience for 10% of android users (something on the order of 200 million people), and about 5% of Windows users.
This project aimed to make Chromium run faster and better by improving its accessibility code. This will result in quicker loading, better performance, less memory usage, longer battery life, and fewer crashes for users. Our main goal is to boost performance and clean up the code.
Naturally, we tackled several sub-projects during this journey. Let's discuss each one individually, highlighting the upcoming steps for each, if any.
There's data structure called an accessibility tree which is a tree mirroring the DOM tree but used to answer accessibility queries. The idea is that very often when a device wants something from that accessibility tree, it may be dirty and thus these events need to be scheduled to be processed later when the tree's clean. Previously, such events were scheduled via closures where a callback was moved into a data structure queue. This approach had a lot of overhead in just unwrapping the closures. As a solution, we refactored this section of the code to utilize an enum-driven approach. In this approach, events are identified by specific enum values, and the corresponding method is invoked once the a11y tree is clean. This is achieved by associating each enum value with its respective target method.
- Began by studying the a11y docs to understand how everything works in general.
- Wrote a new improved code that uses a simplified enum-driven approach as well as cleaned the code in various parts.
- Code was reverted due to a crash reported later on. However, it was fixed and resubmitted in https://chromium-review.googlesource.com/c/chromium/src/+/4706934
Performance improved by over 20% across all accessibility performance tests!
Bounding boxes are essentially the locations of elements in a webpage. It's simply the length and width of the element as well its location from a point relative to its parent like top and left.
- The idea was that we observed an abundance of unnecessary boxes being marked as dirty and updated, even when their boxes remained unchanged. Therefore, we suggested an alternative method to indicate that the bounding boxes of nodes had become dirty. The Intersection Observer presented itself as a suitable option for this purpose.
- Wrote a design doc for how we can maybe improve the bounding box computation by using Intersection Observer.
- Unfortunately Intersection Observer didn't fit the needs required by Bounding Boxes and we found that instead of over-marking dirty objects, we would end up under-marking dirty objects.
- In the end, work was suspended here until we find a better solution.
- Reconsider the available options and think of a better way to avoid this redundant checks.
- May require a custom implementation instead of hooking on an existing system.
We decided to keep the focus on bounding boxes and study the possitibly of adding a new setting (called AXMode) to accessibility to toggle the calculations done on bounding boxes. The aim to is to see an upper-bound on performance improvement.
- All code regarding bounding box computation, serialization and deserialization was placed behind a setting flag that could be toggled.
- An ablation study was created to study the improvements.
- The ablation study showed that a specific test was abnormally better with over 1600% improvement. Thus, another study was started to identify what goes wrong on that test and improve it.
- The ablation study showed that without bounding boxes, performance of accessibility tests improved by over 30%
- The study on the abnormal test identified scrolling as the main culprit and also identified a performance improvement of over 15,000% when fixed. Scrolling is a main source of jank when accessibility is on so this find should help a lot in improving that.
- Discuss proper implementations to patch the findings above and then implement them into the Chromium codebase.
- Codebase Familiarity: Building familiarity with a large and complex codebase like Chromium is a significant challenge. Learning to navigate, understand, and modify various parts of the codebase is a crucial skill. GSoC helped me dive into the codebase and understand many parts of accessibity codebase and even out of it.
- C++ and Git: I thought I knew both when I joined Chromium. But I must say, I've learned a lot about C++ and how it's used in large projects. In addition, I've learned key git features such as
git blameandgit bisectas they were really important in my work. - Debugging and Profiling Skills: Since my project is focused on studying and improving performance. A lot of time was spent in tools like gdb, rr, pref and pprof. It was really challenging and also amazing to learn to use these tools and apply them in a large codebase such as Chromium.
- Collaborative Development: The project involved collaboration with other engineers. Learning how to communicate effectively, use code review tools, and work in a team were very valuable and I learned a lot from my mentor and other engineers at Google.
Thanks to everyone who helped me along the way, including the engineers who commented on my findings. But special thanks to:
- Aaron Leventhal for giving me the chance to be a part of Chromium Accessibility and helping me a lot creating the project, amazing help with the work and most importantly the support he has given me.
- Stefan Zager for his immense help along the way with technical difficulties, explaining things I didn't understand as well as unblocking me countless times!