Investigation and Resolution of CPU Non‑Convergence in Browser Engine (Blink) Rendering

Terminology

Browser Engine – the engine that loads and renders web pages. Common engines include Trident (IE), Gecko (Firefox), WebKit (Safari, prototype of Chrome), Blink (Google/Opera). Baidu's engine is based on Blink.

CPU Non‑Convergence – when the CPU usage curve does not drop to 0 after an app is switched to the background or a page becomes invisible.

1. Problem Discovery

High CPU usage caused by the browser engine leads to UI lag, increased battery drain, and crashes. The issue is hard to locate because it depends on page content, device model, and framework. Testing showed that CPU usage remained at 10‑20% after user interaction stopped or the app was backgrounded, indicating non‑convergence.

2. Testing Approaches

Old Test Scheme – loading top‑100 visited pages and monitoring CPU via the TOP command. Drawbacks: high workload, complex page structures, and difficulty reproducing stable results.

New Test Scheme – create a dedicated test page containing dynamic elements (CSS animation, video, timers, JS loading, GIFs) and run two scenarios: (1) app backgrounded, (2) page switched to an invisible window. Advantages: low workload, fixed simple pages, and scenarios close to real user behavior.

Results revealed two problems:

Scenario 1 (invisible window): multiple pages (Test Center, CSS, H5, GIF) showed non‑convergence.

Scenario 2 (app background): the Test Center page showed non‑convergence.

3. Preliminary Analysis

Problem 1 – Dynamic elements keep the page’s layer updating even when invisible, preventing the engine from pausing rendering, thus CPU never reaches 0.

Problem 2 – The Test Center page has no dynamic elements, yet CPU does not converge. Systrace analysis showed that the engine’s main thread and thread_proxy kept working after backgrounding, suggesting either the WebView was not paused or internal logic prevented pausing.

4. Business and Code Analysis

Engine Loading Process – Network request → Loader → HTML & Script parsed into DOM → CSS combined to build Render Tree → Graphics Context handed to platform graphics library for display. The engine loads and draws concurrently.

Engine Rendering Process – The Render Tree is layered to allow partial updates. Updated layers are composited, sent to GL for drawing, and finally displayed. This pipeline is multithreaded and driven by messages.

The overall rendering flow consists of five steps:

Page parsing – DOM tree to GraphicsLayer conversion.

Update notification – detecting changes and notifying.

Tile rasterization – generating textures for changed regions.

Composition – issuing draw commands on the compositor (UI) thread.

Presentation – hardware or software drawing to the screen.

Dynamic elements are placed in separate layers; if their update messages are not paused, the compositor continuously processes them, keeping the CPU busy.

5. Solutions

Problem 1 Solution – Pause the WebView when the page becomes invisible and, after pausing, suspend all WebView processing to save CPU and memory.

Problem 2 Solution – Add the method CompositingReasonFinder::requiresCompositingForPosition to better decide whether a layer needs compositing, removing the buggy scheduleAnimationIfNeeded call. This reduces dirty‑data‑driven updates, stopping the endless compositing loop.

Test Result Comparison

Before optimization:

After optimization:

6. Summary

CPU convergence is critical for user experience. This case study introduced a low‑cost testing scheme that uncovered non‑convergence scenarios, reproduced the bug under weak‑network conditions, and, by analyzing Blink’s source code and bug reports, implemented targeted fixes that restored zero CPU usage when the app is idle, thereby improving overall product performance.