maxmustermann/vscode
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

update cell part doc

Browse source
This commit is contained in:
rebornix 2021-11-22 10:37:25 -08:00
parent 53e8f2c26e
commit e203c00d7e
No known key found for this signature in database
GPG key ID: 181FC90D15393C20
1 changed files with 7 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

10
src/vs/workbench/contrib/notebook/browser/notebook.layout.md
View file

@ -8,16 +8,20 @@ The notebook editor is a virtualized list view rendered in two contexts (mainfra
## Viewport rendering
The rendering of notebook list view is a "guess and validate" process. It will calcuate how many cells/rows it can render within the viewport, have them all rendered, and then ask for their real dimension, and based on the cell/row dimensions it will decide if it needs to render more cells (if there are still some room in the viewport) or remove a few.
The veiewport rendering of notebook list view is a "guess and validate" process. It will calcuate how many cells/rows it can render within the viewport first, have them all rendered, and then ask for their real dimensions, and based on the cell/row dimensions it will decide if it needs to render more cells (if there are still some room in the viewport) or remove a few.
For short, the process is more or less
* Render cell/row (DOM write)
* Read dimensions (DOM read)
The catch here is while rendering a cell/row, if we happen to perform any DOM read operation between DOM write, it will trigger forced reflow and block the UI. To prevent this we would batch all DOM read operatiosn and postpone them untill the list view requests them.
The catch here is if we happen to perform any DOM read operation between DOM write while rendering a cell, it will trigger forced reflow and block the UI. To make it even worse, there are multiple components in a cell and often they are not aware of the existence of each other. When one component is updating its own DOM content, another component might be reading DOM dimensions at the same time. To prevent the unnecessary forced reflow from happening too often, we introduced the concept of `CellPart`. A `CellPart` is an abstract component in a cell and its lifecycle consists of four phases:
* Creation. `CellPart` is usually created on cell template
* Attach. When a cell is being rendered, we would attach the cell with all `CellPart`s by invoking `CellPart#renderCell`.
* Read DOM dimensions. All DOM read operation should be performed in this phase to prepare for the layout update. `CellPart#prepareLayout` will invoked.
* Update DOM positions. Once the list view finish reading DOM dimensions of all `CellPart`s, it will ask each `CellPart` to update its internal DOM nodes' positions, by calling `CellPart#updateLayoutNow`.
The worflow of rendering a code cell with a text output is like below and all operations are synchronous
![render in the core](https://user-images.githubusercontent.com/876920/142806570-a477d315-40f3-4e0c-8079-f2867d5f3e88.png)