sync: rename Event Loop note in Obsidian vault#21
Conversation
Rename in Obsidian-Vault: browser/Event Loop/Event Loop.md -> Event Loop, Microtasks, Macrotasks.md. Updates the two index pages and Rendering Pipeline.md that link to it.
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (10)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughChangesEvent Loop documentation
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant JavaScript as Synchronous JavaScript
participant Microtasks as Microtask Queue
participant Rendering
participant Macrotasks as Macrotask Queue
JavaScript->>Microtasks: enqueue and drain promise callbacks
Microtasks->>Rendering: queue becomes empty
Rendering->>Macrotasks: complete rendering
Macrotasks->>Microtasks: run one task and drain new microtasks
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content-ru/browser/Event` Loop/Event Loop, Microtasks, Macrotasks.md:
- Line 7: Уточните описание Event Loop: замените единую схему «microtasks → rAF
→ render → macrotask» в разделах о порядке выполнения на модель process frame,
где после microtask checkpoint выполняются этапы обновления представления,
включая requestAnimationFrame, IntersectionObserver и финальное обновление
рендера. Укажите, что setTimeout, сетевые и I/O-задачи поступают из разных task
queues, а не из одной FIFO-очереди макротасков, сохранив объяснение поведения
Promise.then и requestAnimationFrame.
In `@content-ru/browser/Event` Loop/Rendering Pipeline.md:
- Line 20: Уточните описание после изменения element.style.width, заменив
утверждение о немедленном следующем шаге после микрозадач и колбэков rAF на
формулировку, что пересчёт откладывается до следующего обновления рендера, когда
браузер решит его выполнить; сохраните пояснение о пометке элемента и поддерева
как «грязных».
- Around line 29-32: Обновите описание transform/opacity в документе и всех
указанных связанных формулировках: не утверждайте, что они всегда выполняются
только на Composite или пропускают Layout/Paint. Сделайте список триггеров
неполным и явно укажите условие, что compositor-only возможен, если элемент уже
находится в отдельном compositing-слое.
In `@content/browser/Event` Loop/Event Loop, Microtasks, Macrotasks.md:
- Line 7: Revise the note’s event-loop explanation to avoid presenting a
browser-wide fixed ordering between tasks, rendering, requestAnimationFrame, and
timers. Keep the microtask-checkpoint behavior explicit, but describe rendering
as occurring at rendering opportunities and acknowledge that browsers select
among multiple task sources. Reframe the raf-to-timeout example and related
claims as illustrative rather than guaranteed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 096f4623-ca52-480e-8394-bfa21e0122cc
📒 Files selected for processing (10)
content-ru/.translation-manifest.jsoncontent-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.mdcontent-ru/browser/Event Loop/Event Loop.mdcontent-ru/browser/Event Loop/Rendering Pipeline.mdcontent-ru/browser/Event Loop/index.mdcontent-ru/browser/index.mdcontent/browser/Event Loop/Event Loop, Microtasks, Macrotasks.mdcontent/browser/Event Loop/Rendering Pipeline.mdcontent/browser/Event Loop/index.mdcontent/browser/index.md
💤 Files with no reviewable changes (1)
- content-ru/browser/Event Loop/Event Loop.md
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@content-ru/browser/Event` Loop/Event Loop, Microtasks, Macrotasks.md:
- Line 7: Уточните описание Event Loop: замените единую схему «microtasks → rAF
→ render → macrotask» в разделах о порядке выполнения на модель process frame,
где после microtask checkpoint выполняются этапы обновления представления,
включая requestAnimationFrame, IntersectionObserver и финальное обновление
рендера. Укажите, что setTimeout, сетевые и I/O-задачи поступают из разных task
queues, а не из одной FIFO-очереди макротасков, сохранив объяснение поведения
Promise.then и requestAnimationFrame.
In `@content-ru/browser/Event` Loop/Rendering Pipeline.md:
- Line 20: Уточните описание после изменения element.style.width, заменив
утверждение о немедленном следующем шаге после микрозадач и колбэков rAF на
формулировку, что пересчёт откладывается до следующего обновления рендера, когда
браузер решит его выполнить; сохраните пояснение о пометке элемента и поддерева
как «грязных».
- Around line 29-32: Обновите описание transform/opacity в документе и всех
указанных связанных формулировках: не утверждайте, что они всегда выполняются
только на Composite или пропускают Layout/Paint. Сделайте список триггеров
неполным и явно укажите условие, что compositor-only возможен, если элемент уже
находится в отдельном compositing-слое.
In `@content/browser/Event` Loop/Event Loop, Microtasks, Macrotasks.md:
- Line 7: Revise the note’s event-loop explanation to avoid presenting a
browser-wide fixed ordering between tasks, rendering, requestAnimationFrame, and
timers. Keep the microtask-checkpoint behavior explicit, but describe rendering
as occurring at rendering opportunities and acknowledge that browsers select
among multiple task sources. Reframe the raf-to-timeout example and related
claims as illustrative rather than guaranteed.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 096f4623-ca52-480e-8394-bfa21e0122cc
📒 Files selected for processing (10)
content-ru/.translation-manifest.jsoncontent-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.mdcontent-ru/browser/Event Loop/Event Loop.mdcontent-ru/browser/Event Loop/Rendering Pipeline.mdcontent-ru/browser/Event Loop/index.mdcontent-ru/browser/index.mdcontent/browser/Event Loop/Event Loop, Microtasks, Macrotasks.mdcontent/browser/Event Loop/Rendering Pipeline.mdcontent/browser/Event Loop/index.mdcontent/browser/index.md
💤 Files with no reviewable changes (1)
- content-ru/browser/Event Loop/Event Loop.md
🛑 Comments failed to post (4)
content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md (1)
7-7: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Files:" git ls-files | rg 'Event Loop|Event Loop, Microtasks, Macrotasks' || true echo echo "Target excerpt:" if [ -f "content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md" ]; then nl -ba "content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md" | sed -n '1,120p' else fd -i 'Event Loop|Mackrotasks?|Microtasks' . | head -50 fiRepository: Faustze/notes
Length of output: 524
🌐 Web query:
WHATWG HTML event loop microtasks post animation frame processing requestAnimationFrame render queue update style💡 Result:
In the WHATWG HTML standard, the event loop coordinate script execution, tasks, microtasks, and rendering through a structured processing model [1][2]. The event loop processes microtasks via a microtask checkpoint, which typically occurs after a task finishes or when the JavaScript execution context stack is empty [1][3]. The "update the rendering" phase is a distinct step in the event loop processing model for browsing contexts [1][4]. While specifications historically described this phase as running after every task, in practice, it is throttled to align with the display's refresh rate (e.g., 60Hz) [3][5]. The "update the rendering" process includes several sub-steps, which occur in a specific order: 1. Update animations and fire animation events [3]. 2. Fire fullscreen events [3]. 3. Run requestAnimationFrame callbacks [3][6]. 4. Update intersection observations [3]. 5. Update the rendering (finalizing style and layout calculations and performing the actual paint/draw to the screen) [3]. requestAnimationFrame callbacks are executed during this rendering update phase, specifically before the browser performs layout and style calculations and the final paint [3][5]. This ensures that changes made within these callbacks are reflected in the next rendering frame [5]. It is important to note that the exact integration of "update the rendering" into the event loop is a subject of ongoing refinement in the HTML specification to better align with browser implementation realities, such as how different browsers handle timestamps for requestAnimationFrame or manage rendering as a distinct "task" [7][8].
Citations:
- 1: https://html.spec.whatwg.org/multipage/webappapis.html
- 2: https://html.spec.whatwg.org/dev/webappapis.html
- 3: https://github.com/chrishtr/rendering/blob/master/rendering-event-loop.md
- 4: whatwg/html@b0da8d3
- 5: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame.
- 6: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0046.html
- 7: whatwg/html#10007
- 8: whatwg/html#9824
🏁 Script executed:
#!/bin/bash set -euo pipefail python3 <<'PY' from pathlib import Path p = Path("content-ru/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md") lines = p.read_text(encoding="utf-8").splitlines() for i in range(1, min(len(lines), 101) + 1): print(f"{i:3}: {lines[i-1]}") PYRepository: Faustze/notes
Length of output: 5292
🌐 Web query:
HTML standard event loop run microtasks before rendering update processing model task queue💡 Result:
According to the HTML standard's event loop processing model, microtasks are indeed processed before the rendering update steps [1][2]. The event loop continually performs a series of steps [1]. Within each iteration, the sequence is designed to ensure that the microtask queue is fully cleared before the rendering update logic is executed [1][3]. The relevant portion of the event loop processing model [4][5] is structured as follows: 1. Task Selection: The event loop selects the oldest task from one of its task queues and runs it [1][3]. 2. Microtask Checkpoint: Immediately after a task completes (and before any subsequent processing), the event loop performs a "microtask checkpoint" [4][3]. This step processes all tasks currently in the microtask queue [1][3]. If any microtasks queue additional microtasks, those are also processed in this same checkpoint until the microtask queue is empty [3]. 3. Update the Rendering: After the microtask checkpoint is complete, the event loop proceeds to the "update the rendering" steps [1][2]. These steps include processing resize/scroll observers, requestAnimationFrame callbacks, intersection observers, and finally, updating the layout, painting, and compositing [2][5]. Because the rendering update steps occur after the microtask checkpoint, any DOM changes or other work triggered by microtasks will be reflected in the subsequent rendering update [3][6]. This order is a deliberate mechanism to allow scripts to perform cleanup or state updates synchronously—without interleaving with rendering—before the browser performs visual updates [3][6].
Citations:
- 1: https://www.w3.org/TR/2017/REC-html52-20171214/webappapis.html
- 2: https://srekaravarshan.hashnode.dev/part-5-the-event-loop-mechanically
- 3: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide
- 4: https://html.spec.whatwg.org/multipage/webappapis.html
- 5: https://github.com/chrishtr/rendering/blob/master/rendering-event-loop.md
- 6: https://javascript.info/event-loop
Уточните модели для
rAFиrender.Микротаски действительно очищаются перед рендерингом, но не в одну общую
microtasks → rAF → render → macrotaskочередь. Спецификация описываетrAF,intersection observer, и финальное обновление рендера как части обновления представления после checkpoint микротасков в рамках process frame;setTimeout/сетевые/I/O задачи берутся из разных task queues, а не из одной FIFO-очереди макротасков. Сейчас текст создаёт упрощённую, но неспецификационную картину порядка для линий 16-18, 24-38, 44-54, 58-83.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content-ru/browser/Event` Loop/Event Loop, Microtasks, Macrotasks.md at line 7, Уточните описание Event Loop: замените единую схему «microtasks → rAF → render → macrotask» в разделах о порядке выполнения на модель process frame, где после microtask checkpoint выполняются этапы обновления представления, включая requestAnimationFrame, IntersectionObserver и финальное обновление рендера. Укажите, что setTimeout, сетевые и I/O-задачи поступают из разных task queues, а не из одной FIFO-очереди макротасков, сохранив объяснение поведения Promise.then и requestAnimationFrame.Source: MCP tools
content-ru/browser/Event Loop/Rendering Pipeline.md (2)
20-20: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "== file excerpt ==" nl -ba content-ru/browser/Event Loop/Rendering Pipeline.md | sed -n '1,25p;105,120p' || true echo echo "== locale/routing files for Rendering Pipeline / Event Loop ==" git ls-files | grep -E 'content-ru/browser/Event Loop/(Rendering Pipeline|Event Loop)\.md|content-ru/browser/Event Loop' | head -80 echo echo "== related phrases ==" rg -n "естественной точки рендера|шага, который идёт сразу|микрозадач|rAF|requestAnimationFrame|обновление рендера" content-ru/browser/Event Loop/Rendering Pipeline.md content-ru/browser/Event Loop/Event Loop.md 2>/dev/null || trueRepository: Faustze/notes
Length of output: 452
🌐 Web query:
HTML event loop requestAnimationFrame rendering task rendering step microtask checkpoint specification💡 Result:
According to the HTML specification's event loop processing model, the event loop continuously cycles through several distinct phases to coordinate tasks, microtasks, and rendering [1][2][3]. 1. Task Execution: In each iteration, the event loop selects the oldest runnable task from a task queue and executes it to completion [2][3][4]. 2. Microtask Checkpoint: After a task completes, and specifically whenever the JavaScript execution context stack becomes empty, the event loop performs a microtask checkpoint [4][5][6]. This process executes all pending microtasks in the microtask queue [5][6]. If a microtask itself adds more microtasks to the queue, those are also processed during this same checkpoint until the queue is exhausted [4][5][6]. 3. Rendering Step: The event loop checks for a "rendering opportunity"—a user-agent-defined moment typically aligned with the display's refresh rate (VSync) [2][3]. If a rendering opportunity exists, the browser runs the "update the rendering" steps [2][3]. This phase includes: - Executing requestAnimationFrame (rAF) callbacks [2][3]. - Processing intersection observers, resize observers, and other layout/style-related steps [2][3]. - Painting and compositing [2][3]. Critical Relationship: - requestAnimationFrame (rAF) callbacks are not tasks themselves; they are executed as part of the rendering step [7]. - Microtask checkpoints can occur multiple times within a single iteration of the event loop [5]. Specifically, a checkpoint is triggered whenever a script finishes running and the stack is empty, including after an individual callback or an rAF callback, depending on the browser's implementation of the "clean up after running script" algorithm [8][9][6]. Because microtasks run after each script execution (if the stack is empty), they can execute after individual rAF callbacks before the next rAF callback or the subsequent rendering steps begin [8][9].
Citations:
- 1: https://html.spec.whatwg.org/multipage/webappapis.html
- 2: https://srekaravarshan.hashnode.dev/part-5-the-event-loop-mechanically
- 3: https://sujeet.pro/articles/browser-event-loop
- 4: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide/In_depth
- 5: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide
- 6: https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/
- 7: https://devhide.com/which-queue-is-associated-with-requestanimationframe-77008112
- 8: whatwg/html#2637
- 9: gpuweb/gpuweb#596
🌐 Web query:
site:html.spec.whatwg.org rendering steps after requestAnimationFrame microtasks can be skipped update the rendering💡 Result:
In the browser event loop, the steps to "update the rendering" typically follow the execution of script tasks and their associated microtask checkpoints [1][2][3]. Regarding the relationship between requestAnimationFrame (rAF) callbacks and the rendering steps: 1. Microtask Processing: Microtasks (queued via queueMicrotask, Promise resolutions, etc.) are processed immediately after the JavaScript execution context stack becomes empty [1][3]. This occurs after a task finishes running but before the browser proceeds to subsequent steps, such as rendering [1][2][3]. 2. requestAnimationFrame: rAF callbacks are specifically designed to run before the next "update the rendering" step [1][3]. The browser maintains a list of animation frame callbacks and invokes them as part of the rendering pipeline [4]. 3. Can Rendering be Skipped?: While the browser attempts to render at a cadence (typically 60Hz), rendering steps are not strictly guaranteed to occur after every single event loop task or microtask checkpoint. If a browser determines that a frame is unnecessary (e.g., the page is in the background, the screen is not updating, or the browser is resource-constrained), it may skip the rendering steps for that cycle [5][6]. In summary, microtasks run immediately after synchronous JavaScript [1][3], and rAF callbacks run before the rendering update [1][3]. The browser ultimately decides whether to perform the "update the rendering" steps based on factors like display refresh rates and document visibility, meaning rendering can indeed be skipped or deferred even if rAF callbacks have been executed [5].
Citations:
- 1: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
- 2: https://html.spec.whatwg.org/multipage/webappapis.html
- 3: https://html.spec.whatwg.org/dev/timers-and-user-prompts.html
- 4: https://html.spec.whatwg.org/dev/imagebitmap-and-animations.html
- 5: https://html.spec.whatwg.org/multipage/rendering.html
- 6: https://html.spec.whatwg.org/multipage/dom.html
Уточните, что рендеринг может отложиться после rAF.
Текст показывает layout как следующий шаг сразу после микротасок и rAF, но этап обновления рендера выполняется на возможностями браузера и может быть отложен или пропущен. Лучше написать «до следующего обновления рендера, когда браузер решит его выполнить».
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content-ru/browser/Event` Loop/Rendering Pipeline.md at line 20, Уточните описание после изменения element.style.width, заменив утверждение о немедленном следующем шаге после микрозадач и колбэков rAF на формулировку, что пересчёт откладывается до следующего обновления рендера, когда браузер решит его выполнить; сохраните пояснение о пометке элемента и поддерева как «грязных».Source: MCP tools
29-32: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Repository files matching target:" fd -a 'Rendering Pipeline\.md$' . || true echo echo "Target excerpt and relevant occurrences:" file='content-ru/browser/Event Loop/Rendering Pipeline.md' if [ -f "$file" ]; then wc -l "$file" sed -n '1,140p' "$file" | nl -ba else echo "target file not found" fi echo echo "Search for transform/opacity/composite mentions in target and nearby Russian content:" rg -n "Composite|компози(ci|ц)|transform|opacity|свой(с?ственный)|слой|Пен|Paint|Layout|Только" "$file" || trueRepository: Faustze/notes
Length of output: 463
🏁 Script executed:
#!/bin/bash set -euo pipefail file='content-ru/browser/Event Loop/Rendering Pipeline.md' echo "Line count:" wc -l "$file" echo echo "Target excerpt:" awk '{printf "%6d %s\n", NR, $0}' "$file" | sed -n '1,140p' echo echo "Mentions:" rg -n "Composite|компози(ci|ц)|transform|opacity|свой(с?ственный)|слой|Paint|Layout|Только|может пропустить|animati" "$file" || true echo echo "Check whether table markers nearby:" awk '/^Layout:|Paint:|Сло|anim|only|composit/i || NR>=110 && NR<=115 {printf "%6d %s\n", NR, $0}' "$file"Repository: Faustze/notes
Length of output: 20735
🌐 Web query:
web.dev animations guiding principle transform opacity compositor only if own layer💡 Result:
To achieve high-performance animations on the web, the guiding principle is to restrict animated properties to transform and opacity and ensure the element is promoted to its own compositor layer [1][2][3]. Why this works: 1. Compositor-Only Properties: Transform and opacity are considered compositor-only because they can be updated by the browser's compositor thread without triggering the expensive main-thread tasks of style, layout, or paint [4][5][6]. 2. Layer Promotion: When an element is promoted to its own compositor layer (a dedicated GPU texture), the compositor can manipulate its transform or opacity independently using the GPU [4][5]. If an element is not on its own layer, the browser may be forced to perform additional work, potentially leading to jank [1][4]. 3. Performance Benefits: Animating these properties on their own layer allows the browser to bypass most of the rendering pipeline, resulting in smooth animations (ideally 60 FPS) that remain fluid even if the main thread is busy with JavaScript or other heavy tasks [7][1][6]. How to implement: - Use
will-change: transformorwill-change: opacityto hint that these properties will change, allowing the browser to promote the element to a layer ahead of time [8][1][9]. - For older browsers or as a fallback, you can force layer creation usingtransform: translateZ(0)[8][1]. - Caution: While layer promotion is beneficial, it should be used judiciously. Each new layer requires system memory and management overhead; overusing layer promotion can negatively impact performance, particularly on memory-constrained devices like mobile phones [1][10][11]. In summary, the most efficient animations happen when the browser skips the main thread entirely by using compositor-only properties on elements that have been promoted to their own dedicated layers [1][3][6].Citations:
- 1: https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count
- 2: https://web.dev/articles/animations-and-performance
- 3: https://www.browser-rendering.com/compositing-and-gpu-acceleration/animation-performance-patterns/
- 4: https://www.css-animation.com/performance-budgeting-gpu-architecture/compositor-only-property-optimization/
- 5: https://www.browser-rendering.com/compositing-and-gpu-acceleration/transform-and-opacity-best-practices/why-transform-and-opacity-are-gpu-accelerated/
- 6: https://sujeet.pro/articles/crp-rendering-pipeline-overview
- 7: https://web.dev/articles/animations-overview
- 8: https://web.dev/articles/animations-guide
- 9: https://www.cssshowcase.com/articles/animation/gpu-layers-and-will-change-for-transitions
- 10: https://web.dev/articles/speed-layers
- 11: https://sujeet.pro/articles/crp-layerize
Сделайте compositor-only утверждения условными.
В строках 32, 54-56, 75, 80 и 112
transform/opacityописаны так, будто они всегда полностью обходятLayout/Paint; на самом деле это работает только для элементов, уже попавших на отдельный слой компоузинга. Сделайте список триггеров неполным и в формулировках замените «только Composite / пропускают оба шага» на «могут проходить через compositor-only, если элемент уже в отдельном слое».🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content-ru/browser/Event` Loop/Rendering Pipeline.md around lines 29 - 32, Обновите описание transform/opacity в документе и всех указанных связанных формулировках: не утверждайте, что они всегда выполняются только на Composite или пропускают Layout/Paint. Сделайте список триггеров неполным и явно укажите условие, что compositor-only возможен, если элемент уже находится в отдельном compositing-слое.Source: MCP tools
content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md (1)
7-7: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Repository files matching target:" fd -a 'Event Loop, Microtasks, Macrotasks.md|Event Loop' . || true target='content/browser/Event Loop/Event Loop, Microtasks, Macrotasks.md' if [ -f "$target" ]; then echo echo "Line count:" wc -l "$target" echo echo "Target content:" cat -n "$target" else echo "Target file not found; searching similar files..." fd -a 'Event Loop|Microtasks|Macrotasks' . fiRepository: Faustze/notes
Length of output: 5717
🌐 Web query:
WHATWG HTML spec event loop task sources microtasks requestAnimationFrame setTimeout order task queue💡 Result:
According to the WHATWG HTML specification, the event loop coordinates tasks and microtasks to maintain the consistency of the web platform [1][2]. The processing model for an event loop iteration operates in a specific sequence, which determines how tasks, microtasks, and rendering operations relate to each other [1][3]. Key components and their order in the event loop: 1. Task Queues: An event loop has one or more task queues (each associated with a specific task source, such as the timer task source used by setTimeout) [4][3]. In each iteration, the event loop selects the oldest runnable task from one of the task queues and executes it [4][5]. 2. Microtask Checkpoint: After a task finishes (and the JavaScript execution context stack is empty), the event loop performs a microtask checkpoint [1][6]. This involves processing the entire microtask queue [4][5]. If any microtasks queue further microtasks, they are also executed in this same checkpoint until the microtask queue is empty [5][7]. 3. Rendering Update: If the event loop is a window event loop, it may perform rendering update steps [3]. This phase includes executing requestAnimationFrame callbacks, as well as tasks like style recalculation, layout, and painting [3]. Execution Order: - Tasks (like those from setTimeout): These are scheduled in task queues. Only one task is processed per iteration of the event loop [5][3]. - Microtasks (like those from Promise.then or queueMicrotask): These are processed immediately after each task completes, before the event loop proceeds to the next task or the rendering steps [7][3]. This means all microtasks are exhausted before the next task or rendering update can occur [5][7]. - requestAnimationFrame: These callbacks are executed as part of the rendering update steps, which occur after the task has finished and the microtask queue has been fully drained [3]. In summary, the execution order within an event loop iteration is: 1. Run a single task (e.g., a setTimeout callback) [5][3]. 2. Perform a microtask checkpoint (run all queued microtasks) [5][7]. 3. If applicable, perform rendering update steps (which includes executing requestAnimationFrame callbacks) [3].
Citations:
- 1: https://html.spec.whatwg.org/multipage/webappapis.html
- 2: https://html.spec.whatwg.org/dev/webappapis.html
- 3: https://srekaravarshan.hashnode.dev/part-5-the-event-loop-mechanically
- 4: whatwg/html@f4e2907
- 5: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide/In_depth
- 6: https://html.spec.whatwg.org/multipage/timers-and-user-prompts.html
- 7: https://javascript.info/event-loop
🏁 Script executed:
#!/bin/bash set -euo pipefail echo "Search for relevant Event Loop index/rendering link targets:" for f in content/browser/Event Loop/index.md content/browser/Event Loop/"Rendering Pipeline — what happens after the microtask queue drains".md content-ru/browser/Event Loop/index.md content-ru/browser/Event Loop/"Rendering Pipeline — what happens after the microtask queue drains".md; do if [ -f "$f" ]; then echo "--- $f" cat -n "$f" fi doneRepository: Faustze/notes
Length of output: 212
🌐 Web query:
WHATWG HTML spec "processing task queues" "select a runnable task" "rendering update steps"💡 Result:
In the modern WHATWG HTML specification, "update the rendering" is handled as a task on the rendering task source, rather than a post-task operation performed after every task iteration [1]. Key aspects of this processing model include: 1. Task Selection and Execution: The event loop continuously processes tasks from various task queues (which are sets, not strict FIFO queues) [2][3]. When a task source has a runnable task, the event loop selects it and executes it to completion [1][3]. 2. Rendering Opportunity: User agents (UAs) define "rendering opportunities," which are specific points in time where the browser may update the rendering—typically aligned with the display's refresh rate (e.g., 60Hz) [1][2]. 3. The Update-the-rendering Task: When a rendering opportunity occurs, the UA queues a specific task—the "update the rendering" task—on the rendering task source [1][2]. This task is processed by the event loop just like any other task [1][4]. 4. Contents of the Rendering Update: This task executes a comprehensive, ordered sequence of steps [1]. While implementations may vary slightly, these steps typically include: - Resizing and scrolling updates [5] - Media query evaluations [5] - Updating animations and firing related events [4][5] - Running requestAnimationFrame (rAF) callbacks [1][5] - Updating intersection observers [5] - Style recalculation, layout, and painting (the actual rendering) [1][5] This refactor (formally incorporated around early 2024 via PR
#10007) moved rendering from a mandatory post-task operation to a scheduled task, allowing the browser to better manage rendering updates alongside other tasks [1]. Microtask checkpoints, by contrast, continue to run after each individual task execution, separate from the rendering task source [1][3].Citations:
- 1: https://sujeet.pro/articles/browser-event-loop
- 2: https://theaispace.xyz/articles/the-browser-event-loop-task-queues-and-rendering-en
- 3: https://cloud.mo4tech.com/eventloop-share.html
- 4: servo/servo#31242
- 5: https://github.com/chrishtr/rendering/blob/master/rendering-event-loop.md
🌐 Web query:
MDN window.requestAnimationFrame callback order microtasks macro tasks render loop💡 Result:
In the browser event loop, window.requestAnimationFrame (rAF) callbacks are neither macrotasks nor microtasks; instead, they are executed as part of the browser's "update the rendering" steps [1][2][3]. The ordering of these operations within a single iteration of the event loop generally follows this flow: 1. Task: One task is pulled from the task queue and executed [4][5][6]. 2. Microtasks: Immediately after the task exits (and the execution context stack is empty), all pending microtasks are executed until the microtask queue is empty [4][5][7]. 3. Rendering Update: If it is a "rendering opportunity," the browser performs rendering steps [8][3]. This phase includes: - Resize, scroll, and IntersectionObserver callbacks [3]. - Execution of rAF callbacks [2][3]. - Style, layout, and paint [3]. Crucially, because microtasks are processed whenever the execution context stack is empty, any microtasks queued during a rAF callback will be executed before the browser proceeds to the style, layout, and paint steps of that same rendering frame [2]. Conversely, if a rAF callback calls requestAnimationFrame again, that new callback is scheduled for the next rendering update, not the current one [9][7].
Citations:
- 1: https://stackoverflow.com/questions/70995372/is-requestanimationframe-belong-to-microtask-or-macrotask-in-main-thread-task-ma
- 2: https://dev.to/marshateo/requestanimationframe-the-missing-scheduling-layer-1el0
- 3: https://github.com/ChennakeshavaG/blurrysite/blob/main/docs%2Fresearch%2Fscheduling-foundations.md
- 4: https://developer.mozilla.org/en-US/docs/Web/API/HTML%5FDOM%5FAPI/Microtask%5Fguide
- 5: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide/In_depth
- 6: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Execution_model
- 7: https://sujeet.pro/articles/browser-event-loop
- 8: https://github.com/chrishtr/rendering/blob/master/rendering-event-loop.md
- 9: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame
🌐 Web query:
WHATWG HTML task queue definition task source oldest runnable task implementation-defined task source💡 Result:
In the WHATWG HTML Standard event-loop processing model, the relevant concepts are: 1) “Task source” (definition) A task has a “source” field (a task source). Task sources are categories that determine which task queue a task is placed on, and ordering guarantees apply within a task source/queue. When a user agent queues a task, it must add it to one of the event loop’s task queues; tasks from the same task source must go to the same task queue, while tasks from different task sources may go to different queues [1]. 2) “Oldest runnable task” During event-loop processing, if there is at least one runnable task in one of the event loop’s task queues, the algorithm selects the oldest runnable task: “Let oldestTask be the oldest task on one of the event loop’s task queues … [ignoring] … tasks whose associated Documents are not fully active.” The UA “may pick any task queue” [2]. 3) “Implementation-defined task queue selection” The event loop’s choice of which task queue to take from (when multiple queues may have runnable tasks) is not fixed by the spec: “The user agent may pick any task queue.” This makes the selection across task queues effectively implementation-defined, while the ordering within the selected queue still respects the “oldest task” rule [2][3]. 4) Putting it together (the selection + execution boundary) Once a task queue is chosen and the oldest runnable task (oldestTask) is selected, that task is removed from its queue and run; then the event loop proceeds to microtasks. The “oldestTask” selection and single-task removal establish the macro-task (event-loop-task) granularity [2]. So, answering the combined query phrase: - “WHATWG HTML task queue definition” refers to event-loop task queues that hold tasks, grouped by task source [1]. - “Task source” is the task’s source category that determines which task queue a task belongs to, with strict ordering guarantees within that source/queue [1]. - “Oldest runnable task” is the oldest runnable task on the chosen queue selected by the event-loop processing model [2]. - “Implementation-defined task source / task queue selection” is that when picking among possible task queues that have runnable tasks, “the user agent may pick any task queue,” making cross-queue ordering implementation-defined [2][3].
Citations:
🌐 Web query:
MDN setTimeout requestAnimationFrame order promise event loop💡 Result:
In the browser event loop, tasks, microtasks, and rendering steps are processed in a specific, repeating order [1][2][3]. The event loop iteration generally follows this sequence [1][2][4]: 1. Task Execution: The event loop selects and executes a single task (such as a setTimeout callback or an event handler) from a task queue [1][2][5]. 2. Microtask Checkpoint: After the task completes, the event loop runs all pending microtasks until the microtask queue is empty [1][3][6]. This includes promise callbacks [7][8]. If new microtasks are added during this phase, they are also executed before moving on [2][5][6]. 3. Update Rendering: If there is a rendering opportunity, the browser performs rendering steps [3][4]. This includes executing requestAnimationFrame callbacks before style calculations, layout, and painting [5][3][4]. In summary, the execution order is: Task -> Microtasks -> requestAnimationFrame (if rendering occurs) [1][2][3][4]. Key points regarding this order: - Microtasks (e.g., Promise.then) always run after a task finishes and before the browser moves to the next rendering phase or event loop iteration [1][2][6]. - requestAnimationFrame callbacks are part of the rendering update steps, not the task or microtask queues [5][4][9]. They are executed immediately before the browser performs a repaint [10][4]. - Because microtasks are processed immediately after a task and before rendering, they will run before any requestAnimationFrame callback triggered during that same task [2][6][11].
Citations:
- 1: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide/In_depth
- 2: https://developer.mozilla.org/en-US/docs/Web/API/HTML%5FDOM%5FAPI/Microtask%5Fguide
- 3: https://srekaravarshan.hashnode.dev/part-5-the-event-loop-mechanically
- 4: https://stackoverflow.com/questions/43050448/when-will-requestanimationframe-be-executed
- 5: https://sujeet.pro/articles/browser-event-loop
- 6: https://developer.mozilla.org/en-US/docs/Web/API/HTML_DOM_API/Microtask_guide
- 7: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises
- 8: https://developer.mozilla.org/en-US/docs/Web/API/Window/setTimeout
- 9: https://stackoverflow.com/questions/70995372/is-requestanimationframe-belong-to-microtask-or-macrotask-in-main-thread-task-ma
- 10: https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame
- 11: https://stackoverflow.com/questions/78012547/how-to-implement-requestanimationframe-loop-with-asynchronous-callback
Avoid claiming one browser-wide execution order.
The note still presents rendering as a fixed step after every task and makes
raf → timeoutsound guaranteed. The browser has multiple task queues/sources and implementation-defined selection between them; rendering is tied to rendering opportunities rather than guaranteed after every loop. Keep the microtask-checkpoint behavior explicit, but frame the task/rendering/macrotask relationship and the example as illustrative.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@content/browser/Event` Loop/Event Loop, Microtasks, Macrotasks.md at line 7, Revise the note’s event-loop explanation to avoid presenting a browser-wide fixed ordering between tasks, rendering, requestAnimationFrame, and timers. Keep the microtask-checkpoint behavior explicit, but describe rendering as occurring at rendering opportunities and acknowledge that browsers select among multiple task sources. Reframe the raf-to-timeout example and related claims as illustrative rather than guaranteed.Source: MCP tools
1 participant
Summary
npm run syncpicked up a rename in Obsidian-Vault:browser/Event Loop/Event Loop.md->Event Loop, Microtasks, Macrotasks.md. Updated the two index pages andRendering Pipeline.mdthat linked to the old name.content-ru/.These commits were originally pushed to
chore/translate-browser-notesbut landed after PR #20 had already been merged, so they never reachedmain. Re-applying them here.Test plan
npm run translate:checkreports content-ru/ up to datenpm run check(tsc + prettier) passesSummary by CodeRabbit
requestAnimationFrame.