Performance Optimization of Tencent Docs SmartSheet View: Incremental Rendering, Flame Graph Analysis, and Offscreen Rendering

Tencent Docs SmartSheet view suffered from low frame rates (around 20 FPS) compared to the regular Sheet view (≈58 FPS), resulting in a noticeably sluggish user experience.

The engineering team investigated the problem and applied a series of optimizations, including disabling color picking, reducing search result matching, avoiding heavy clone operations, and implementing multi‑card offscreen rendering.

Incremental Rendering : The rendering pipeline was broken into four stages—collecting text dimensions, gathering widget trees, recursive painting, and batch drawing via Konva. Only widgets within the visible area are rendered; during scroll, the system calculates which cards need to be destroyed or created and performs incremental painting.

Flame Graph Analysis : Chrome Performance recordings revealed expensive tasks, especially repeated calls to getImageData . The team measured the cost of 1000 calls, which took roughly 245‑255 ms, confirming that canvas hit‑testing was a major bottleneck.

Navigated to file xx
getImageData 1000次: 250.051025390625 ms
Navigated to file xx
getImageData 1000次: 245.02587890625 ms
Navigated to file xx
getImageData 1000次: 245.637939453125 ms
Navigated to file xx
getImageData 1000次: 254.847900390625 ms

To mitigate this, the team disabled listening on the layer during scroll (debounced wheel events) and set layer.isListening = false to skip hit‑testing.

Avoiding Clone : Previously, nodes were cloned and then reconfigured, which caused deep‑copy overhead. The solution replaced cloning with direct construction of new nodes using cached configuration objects.

Text Caching : Text measurement and line‑breaking were expensive due to binary search and repeated measureText calls. The team introduced a cache storing text width, height, and line break indices, reducing the need for repeated calculations. They also limited cached line data to the first four lines (the visible portion) and stored only break indices to save memory.

Offscreen Rendering : An offscreen canvas was added to each group. During drawing, if an offscreen canvas exists, the group is rendered via drawImage from the offscreen buffer, dramatically reducing redraw time for unchanged content. This approach works best for multi‑card scenarios, where only newly visible cards need full rendering.

After applying these optimizations, FPS approached 60 frames, effectively doubling performance. The team also recommends moving heavy calculations to Web Workers and leveraging native OffscreenCanvas for further gains.

Key takeaways: avoid main‑thread blocking during scroll, cache expensive computations, minimize deep copies, and use offscreen rendering to reuse previously drawn content.