Standardize on "Dirty flag" not "dirty bit" (27 vs 37 uses)

Author: pavpanchekha

book/animations.md

@@ -854,7 +854,7 @@ class Browser:
 All that's left is wiring these methods up; let's rename
 `raster_and_draw` to `composite_raster_and_draw` (to remind us that
 there's now an additional composite step) and add our two new methods.
-(And don't forget to rename the corresponding dirty bit and call
+(And don't forget to rename the corresponding dirty flag and call
 sites.)
 
 ``` {.python}
@@ -1167,7 +1167,7 @@ class Tab:
 Inside this loop we need to do two things. First, call the
 animation's `animate` method and save the new value to the node's
 `style`. Second, since that changes rendering inputs, set a
-dirty bit requiring rendering later.^[We also need to
+dirty flag requiring rendering later.^[We also need to
 schedule an animation frame for the next frame of the animation, but
 `set_needs_render` already does that for us.] The whole rendering cycle between the browser and main threads is summarized
 in Figure 2.
@@ -1203,7 +1203,7 @@ class Tab:
 
 To implement `set_needs_layout`, we've got to replace the single
 `needs_render` flag with three flags: `needs_style`, `needs_layout`,
-and `needs_paint`. In our implementation, setting a dirty bit earlier
+and `needs_paint`. In our implementation, setting a dirty flag earlier
 in the pipeline will end up causing everything after it to also run,^[This
 is yet another difference from real browsers, which optimize some
 cases that just require style and paint, or other combinations.]
@@ -1233,8 +1233,8 @@ class Tab:
         self.browser.set_needs_animation_frame(self)
 ```
 
-To support these new dirty bits, `render` must check each phase's bit
-instead of checking `needs_render` at the start:[^timer-obsolete]
+To support these new dirty flags, `render` must check each phase's
+flag instead of checking `needs_render` at the start:[^timer-obsolete]
 
 ``` {.python}
 class Tab:
@@ -1414,9 +1414,9 @@ class Tab:
 ```
 
 Now for the browser thread. First, add `needs_composite`, `needs_raster` and
-`needs_draw` dirty bits and corresponding `set_needs_composite`,
+`needs_draw` dirty flags and corresponding `set_needs_composite`,
 `set_needs_raster`, and `set_needs_draw` methods (and remove the old dirty
-bit):
+flag):
 
 ``` {.python}
 class Browser:
@@ -2316,7 +2316,7 @@ function, and one or two others.
 transfoms and scrolling, but they are not fully composited and threaded,
 and transform transition animations are not supported. Implement these.
 (Hint: for transforms, it just requires following the same pattern as for
-`opacity`; for scrolling, it requires setting fewer dirty bits in
+`opacity`; for scrolling, it requires setting fewer dirty flags in
 `handle_down`.) [A simultaneous transform and opacity animation][tr-example] should now work, without any raster, and scrolling on that page should not
 raster either.
 

book/embeds.md

@@ -1000,7 +1000,7 @@ class Frame:
             # ...
 ```
 
-Again, these dirty bits move to the `Frame` because they relate to the
+Again, these dirty flags move to the `Frame` because they relate to the
 frame's part of rendering.
 
 Unlike images, iframes have *no [intrinsic size][intrinsic-size]*:

book/glossary.md

@@ -385,6 +385,11 @@ Device pixel ratio
 : The ratio between the screen pixel resolution and a
 "typical" screen (defined as the pixel resolution of a 1990s CRT).
 
+Dirty flag
+
+: A boolean variable that indicates whether some other piece of data
+  is up to date and thus usable or out of date and thus invalidated.
+
 Display list
 
 : A sequence of graphics commands explaining how to draw a

book/invalidation.md

@@ -531,9 +531,9 @@ class Frame:
 ```
 
 It's important that _all_ dependencies of the protected field set the
-dirty bit. This can be challenging, since it requires being vigilant
+dirty flag. This can be challenging, since it requires being vigilant
 about which fields depend on which others. But if we do forget to set
-the dirty bit, we'll sometimes fail to recompute the protected
+the dirty flag, we'll sometimes fail to recompute the protected
 fields, which means we'll display the page incorrectly. Typically
 these bugs look like unpredictable layout glitches, and they can be
 very hard to debug---so we need to be careful.
@@ -1895,9 +1895,9 @@ Skipping Traversals
 ===================
 
 Now that all of the layout fields are protected, we can check if any
-of them need to be recomputed by checking their dirty bits. But to
-check all of those dirty bits, we'd need to *visit* every layout object,
-which can take a long time. Instead, we should use dirty bits to
+of them need to be recomputed by checking their dirty flags. But to
+check all of those dirty flags, we'd need to *visit* every layout object,
+which can take a long time. Instead, we should use dirty flags to
 minimize the number of layout objects we need to visit.
 
 The basic idea revolves around the question: do we even need to call
@@ -1916,7 +1916,7 @@ descendant has a dirty `ProtectedField`:[^ancestors]
 
 [^ancestors]: In some code bases, you will see these called *ancestor*
     dirty flags instead. It's the same thing, just following the flow
-    of dirty bits instead of the flow of control.
+    of dirty flags instead of the flow of control.
 
 ``` {.python}
 class BlockLayout:
@@ -1957,29 +1957,29 @@ class BlockLayout:
 ```
 
 Then, whenever `mark` or `notify` is called, we set the descendant
-bits by walking the `parent` chain:
+flags by walking the `parent` chain:
 
 ``` {.python}
 class ProtectedField:
-    def set_ancestor_dirty_bits(self):
+    def set_ancestor_dirty_flags(self):
         parent = self.parent
         while parent and not parent.has_dirty_descendants:
             parent.has_dirty_descendants = True
             parent = parent.parent
 
     def mark(self):
         # ...
-        self.set_ancestor_dirty_bits()
+        self.set_ancestor_dirty_flags()
 ```
 
-Note that the `while` loop exits early if the descendants bit is
-already set. That's because whoever set _that_ bit already set all the
-ancestors' descendant dirty bits.^[This
+Note that the `while` loop exits early if the descendants flag is
+already set. That's because whoever set _that_ flag already set all the
+ancestors' descendant dirty flags.^[This
 optimization is important in real browsers. Without it, repeatedly
 invalidating the same object would walk up the tree to the root repeatedly,
 violating the principle of incremental performance.]
 
-We'll need to clear the descendant bits after `layout`:
+We'll need to clear the descendant flags after `layout`:
 
 ``` {.python}
 class BlockLayout:
@@ -2001,7 +2001,7 @@ class BlockLayout:
         # ...
 ```
 
-Here, the `layout_needed` method just checks all of the dirty bits:
+Here, the `layout_needed` method just checks all of the dirty flags:
 
 ``` {.python}
 class BlockLayout:
@@ -2077,7 +2077,7 @@ pattern][observer-pattern], where one piece of code runs a callback
 when a piece of state changes. This pattern is [common in UI
 frameworks][kvo]. Usually these observers *eagerly* recompute
 dependent results, but our callbacks---`mark` and `notify`---simply set a
-dirty bit to be cleaned up later. That means our invalidation
+dirty flag to be cleaned up later. That means our invalidation
 algorithm is a kind of [*lazy* observer][lazy-eval]. Laziness helps
 performance by batching updates.
 :::
@@ -2644,7 +2644,7 @@ ideal.
 Luckily, techniques like compile-time code generation and macros can
 be used to turn `ProtectedField` objects into straight-line code
 behind the scenes. Setting a particular `ProtectedField` can set the
-dirty bits on statically known invalidations, the dirty bits can be
+dirty flags on statically known invalidations, the dirty flags can be
 inlined into the layout objects, and the `read` function can check
 that the dependency was declared at compile time.^[Real browsers pull
 tricks like that all the time, in order to be super fast but still
@@ -2737,7 +2737,7 @@ invalidation properly.
 [^unless-createelement]: Unless you've implemented Exercises 9-2 and 9-3,
     in which case they can also be "detached" elements.
 
-16-4 *Descendant bits for style*. Add descendant dirty flags for `style`
+16-4 *Descendant flags for style*. Add descendant dirty flags for `style`
 information, so that the `style` phase doesn't need to traverse nodes
 whose styles are unchanged.
 
@@ -2792,5 +2792,5 @@ of `ProtectedField` to be functional rather than object-oriented.
 
 16-10 *Optimizing paint*. Even after making layout fast for text input, paint is
 still painfully slow. Fix that by storing the display list between frames,
-adding dirty bits for whether paint is needed for each layout object, and mutating
+adding dirty flags for whether paint is needed for each layout object, and mutating
 the display list rather than recreating it every time.

book/scheduling.md

@@ -642,8 +642,8 @@ varying rate between 60 and 24.
 [refresh-rate]: https://www.intel.com/content/www/us/en/gaming/resources/highest-refresh-rate-gaming.html
 [hobbit-fps]: https://www.extremetech.com/extreme/128113-why-movies-are-moving-from-24-to-48-fps
 
-Optimizing with Dirty Bits
-==========================
+Optimizing with Dirty Flags
+===========================
 
 If you run this on your computer, there's a good chance your CPU usage
 will spike and your batteries will start draining. That's because
@@ -654,9 +654,9 @@ the web page will not have changed at all, so the old styles, layout
 trees, and display lists would have worked just as well as the new
 ones.
 
-Let's fix this using a *dirty bit*, a piece of state that tells us if
+Let's fix this using a *dirty flag*, a piece of state that tells us if
 some complex data structure is up to date. Since we want to know if we
-need to run `render`, let's call our dirty bit `needs_render`:
+need to run `render`, let's call our dirty flag `needs_render`:
 
 ``` {.python}
 class Tab:
@@ -718,12 +718,12 @@ doing `raster_and_draw` every time the active tab runs a task.
 But sometimes that task is just running JavaScript that doesn't touch
 the web page, and the `raster_and_draw` call is a waste.
 
-We can avoid this using another dirty bit, which I'll call
+We can avoid this using another dirty flag, which I'll call
 `needs_raster_and_draw`:[^not-just-speed]
 
-[^not-just-speed]: The `needs_raster_and_draw` dirty bit doesn't just
+[^not-just-speed]: The `needs_raster_and_draw` dirty flag doesn't just
 make the browser a bit more efficient. Later in this chapter, we'll
-add multiple browser threads, and at that point this dirty bit is
+add multiple browser threads, and at that point this dirty flag is
 necessary to avoid erratic behavior when animating. Try removing it
 later and see for yourself!
 
@@ -777,7 +777,7 @@ class Chrome:
         return False
 ```
 
-And the `Tab` should also set this bit after running `render`:
+And the `Tab` should also set this flag after running `render`:
 
 ``` {.python dropline=set_needs_raster_and_draw}
 class Tab:
@@ -942,7 +942,7 @@ later, they might end up delayed by many, many frames.
 
 Luckily, rendering is special in that it never makes sense to have two
 rendering tasks in a row, since the page wouldn't have changed in
-between. To avoid having two rendering tasks we'll add a dirty bit
+between. To avoid having two rendering tasks we'll add a dirty flag
 called `needs_animation_frame` to the `Browser` that indicates
 whether a rendering task actually needs to be scheduled:
 
@@ -979,7 +979,7 @@ class Browser:
 ```
 
 Note that `set_needs_animation_frame` will only actually set the dirty
-bit if called from the active tab. This guarantees that inactive tabs
+flag if called from the active tab. This guarantees that inactive tabs
 can't interfere with active tabs. Besides preventing scripts from
 scheduling too many animation frames, this system also makes sure that
 if our browser consistently runs slower than 30 frames per second, we

src/lab16.py

@@ -84,7 +84,7 @@ def set_dependencies(self, dependencies):
             dependency.invalidations.add(self)
         self.frozen_dependencies = True
 
-    def set_ancestor_dirty_bits(self):
+    def set_ancestor_dirty_flags(self):
         parent = self.parent
         while parent and not parent.has_dirty_descendants:
             parent.has_dirty_descendants = True
@@ -93,12 +93,12 @@ def set_ancestor_dirty_bits(self):
     def mark(self):
         if self.dirty: return
         self.dirty = True
-        self.set_ancestor_dirty_bits()
+        self.set_ancestor_dirty_flags()
 
     def notify(self):
         for field in self.invalidations:
             field.mark()
-        self.set_ancestor_dirty_bits()
+        self.set_ancestor_dirty_flags()
 
     def set(self, value):
         # if self.value != None: