Reflow-test
├─ .vscode
│  └─ settings.json
├─ app.js
├─ cat.js
├─ imgs
│  ├─ after timer.gif
│  ├─ before timer.gif
│  ├─ cat.gif
│  └─ result.gif
├─ index.html
├─ LICENSE
├─ main.js
├─ style.css
└─ thinking.md

Go to Developer Tools, navigate to the Performance tab, and check the performance :)

---

Investigating Rendering Processes for Each Case

Un-caching TOP

Time Taken to Compose One Frame

It took approximately 138.63ms to compose one frame. This translates to around 7FPS.

Why did this happen?

Execution of Batch DOM Manipulation: ❌

Examining the call tree within a single task, we notice that the getLocation method is executed when the move method of a node is called. If isCaching is false, the getLocation method calculates the current position of the data using offsetTop + trnaslateY(px).

When get offsetTOP is executed, a reflow occurs. Following getLocation, DOM operations of the node are invoked, triggering another reflow.

This sequence repeats for each node.

Recalculate style -> layout processes occur repeatedly for each node.

On average, each layout calculation took 0.30ms. Thus, the lengthy duration for composing one frame was primarily due to the numerous layout calculations.

??? : The browser rendering engine queues DOM operations and processes them collectively, claiming to optimize the process.

The reason for not executing Batch DOM Manipulation is that when the browser engine is asked for the current position of a node, it must execute any previously queued DOM operations before providing the position. This is because DOM operations can trigger reflows, potentially altering the layout of other nodes.

Thus, immediate computation of the current node's Computed Style attribute leads to immediate DOM Manipulation.

Summary

Uncaching TOP suffered from repetitive reflows as Batch DOM Manipulation couldn't be utilized.

Changing the TOP attribute itself triggers a reflow.

Caching TOP

Time Taken to Compose One Frame

It took approximately 16ms to compose one frame, maintaining 60FPS.

Execution of Batch DOM Manipulation: ⭕

Although getLocation is executed in Caching TOP, the method uses cached data when isCaching is true.

Thus, Batch DOM Manipulation is possible, leading to only one layout calculation per task.

The key point is that, despite both Un-caching TOP and Caching TOP triggering a reflow due to changing the TOP attribute, the former incurred numerous reflows (0.3ms * number of nodes), while the latter managed multiple node reflows collectively within 0.4ms.

Un-Caching Translate

Time Taken to Compose One Frame

It took approximately 26.92ms to compose one frame, resulting in around 35FPS.

I thought using translate would be much better than changing the top attribute every time, but it wasn't.

Execution of Batch DOM Manipulation: ❌

Even in Un-Caching Translate, get OffsetTOP is executed, forcing immediate DOM Operation execution.

Consequently, each node triggers Recalculated Style due to changes in the translateY property, although this process is relatively short compared to layout calculation.

As translate is utilized, no layout occurs after Recalculate Style.

Rendering updates are scheduled after the altered styles post Recalculate Style, illustrating a collective rendering process.

Caching Translate

Time Taken to Compose One Frame

It took approximately 16ms to compose one frame, maintaining 60FPS.

Execution of Batch DOM Manipulation: ⭕

In Caching Translate, getLocation utilizes cached data, enabling Batch DOM Manipulation.

Thus, tasks execute Recalculate Style, pre-paint, paint, commit, and other processes collectively.

Notably, the Commit phase takes longer in Caching Translate, unlike other scenarios where it lasts around 0.4ms. Here, it extends to 10ms.

It's unclear whether this delay is due to maintaining 60FPS by waiting at Commit even after completing all processes or because shifting layers during Commit takes longer.

Regardless, Commit occurs only once, so there's no inherent reaso