words

Author: willmcgugan

docs/blog/posts/release1.0.0.md

@@ -65,7 +65,7 @@ Some characters such as those in Asian languages and many emoji are double the w
 
 Textual's way of handling this is inherited from [Rich](https://github.com/Textualize/rich).
 Anything you print in Rich, first generates a list of [Segments](https://github.com/Textualize/rich/blob/master/rich/segment.py) which consist of a string and associated style.
-These Segments are only converted into text with [ansi escape codes](https://en.wikipedia.org/wiki/ANSI_escape_code) at the very end of the process.
+These Segments are converted into text with [ansi escape codes](https://en.wikipedia.org/wiki/ANSI_escape_code) at the very end of the process.
 
 
 The compositor takes lists of segments generated by widgets and further processes them, by dividing and combining, to produce the final output. 
@@ -157,7 +157,7 @@ Widgets may contain other widgets which are clipped to their *parent's* boundari
 
     Not to mention there can be multiple "screens" of widgets stacked on top of each other, with a modal fade effect applied to lower screens. 
 
-The compositor can do partial updates.
+The compositor can also do partial updates.
 In other words, if you click a button and it changes color, the compositor can update just the region occupied by the button.
 
 The compositor does all of this fast enough to enable smooth scrolling, even with a metric tonne of widgets on screen.
@@ -190,7 +190,7 @@ Consider the following arrangement of widgets:
 --8<-- "docs/blog/images/compositor/spatial-map.excalidraw.svg"
 </div>
 
-Here we have 8 widgets, where only around 4 will be visible at any given time, depending on the position of the scrollbar.
+Here we have 8 widgets, where only 3 or 4 will be visible at any given time, depending on the position of the scrollbar.
 We want to avoid doing work on widgets which will not be seen in the next frame.
 
 A naive solution to this would be to check each widget's [Region][textual.geometry.Region] to see if it overlaps with the visible area.
@@ -199,7 +199,7 @@ If we get in to the 1000s of widgets territory, it may become significant &mdash
 
 ### The Grid
 
-The first step in the spatial map is associate every widget with a tile in a regular grid[^2].
+The first step in the spatial map is to associate every widget with a tile in a regular grid[^2].
 
 <div class="excalidraw">
 --8<-- "docs/blog/images/compositor/spatial-map-grid.excalidraw.svg"
@@ -222,8 +222,8 @@ At the end of that process we have a dict that maps every grid coordinate on to
 }
 ```
 
-This data is cacheable.
-If the widgets don't change their position or size such as when user is *scrolling*, then we can reuse the information.
+If the widgets don't change their position or size (such as when user is *scrolling*) then we can re-use this data.
+The up-front cost of [calculating](https://github.com/Textualize/textual/blob/main/src/textual/_spatial_map.py) this data is fairly low.
 
 ### Search the grid
 
@@ -236,7 +236,7 @@ In the following illustration we have scrolled the screen up[^3] a little so tha
 --8<-- "docs/blog/images/compositor/spatial-map-view1.excalidraw.svg"
 </div>
 
-We then determine which grid tiles overlap by the viewable area.
+We then determine which grid tiles overlap the viewable area.
 In the above examples that would be the tiles with coordinates  `(0,0)`, `(1,0)`, `(0,1)`, and `(1,1)`.
 Once we have that information, we can then then look up those coordinates in the spatial map data structure, which would retrieve 4 lists: