Fixup minor Markdown formatting issues in the README.

impeller/README.md

@@ -23,7 +23,6 @@ Impeller is a rendering runtime for Flutter with the following objectives:
 * **Uses Modern Graphics APIs Effectively**: Makes heavy use of (but doesn’t depend on) features available in Modern APIs like Metal and Vulkan.
 * **Makes Effective Use of Concurrency**: Can distribute single-frame workloads across multiple threads if necessary.
 
-
 ## Project Organization
 
 Impeller is a meta-framework. While a user of Impeller may choose to include the whole enchilada (in `//impeller/:impeller`), the various sub-frameworks have clearly defined responsibilities and adhere to a strict hierarchy.
@@ -32,12 +31,10 @@ Impeller itself may not depend on anything in `//flutter` except `//flutter/fml`
 
 An overview of the major sub-frameworks, their responsibilities, and, relative states of completion:
 
-
-
 * **`//impeller/compiler`**: The offline shader compiler. Takes GLSL 4.60 shader source code and converts it into a backend specific shader representation (like Metal Shading Language). It also generates C++ bindings that callers can include as a GN `source_set`s so there is no runtime shader reflection either. The target is an executable called `impellerc` which is never shipped into the binary or as an artifact.
 * **`//impeller/renderer`**: The very lowest level of the renderer that is still backend agnostic. Allows users to build a renderer from scratch with few restrictions. Has utilities for creating allocators, generating pipeline state objects from bindings generated by `//impeller/compiler`, setting up render passes, managing jumbo uniform-buffers, tessellators, etc..
     * **`//impeller/renderer/backend`**: Contains all the implementation details for a specific client rendering API. The interfaces in these targets are meant to be private for non-WSI user targets. No Impeller sub-frameworks may depend on these targets.
-* **`//impeller/archivist**`: Allows persisting objects to disk as performantly as possible (usually on a background thread). The framework is meant to be used for storing frame meta-data and related profiling/instrumentation information. Collection of information should succeed despite process crashes and retrieval of traces must not use inordinate amounts of time or memory (which usually leads to crashes).
+* **`//impeller/archivist`**: Allows persisting objects to disk as performantly as possible (usually on a background thread). The framework is meant to be used for storing frame meta-data and related profiling/instrumentation information. Collection of information should succeed despite process crashes and retrieval of traces must not use inordinate amounts of time or memory (which usually leads to crashes).
 * **`//impeller/geometry`**: All (or, most of) the math! This C++ mathematics library is used extensively by Impeller and its clients. The reasonably interesting bit about this library is that all types can be used interchangeably in device and host memory. Various Impeller subsystems understand these types and can take care of packing and alignment concerns w.r.t these types.
 * **`//impeller/playground`**: When working with graphics APIs, it is often necessary to visually verify rendering results as a specific feature is being worked upon. Moreover, it is useful to attach frame debuggers or profilers to specific test cases. The playground framework provides Google Test fixtures that open the current state of various rendering related objects in a window in which rendering results can be visualized, or, to which frame debuggers can be attached. Most Impeller sub-frameworks that have a test harness also have a custom playground subclass. This sub-framework is only meant to provide utilities for tests and will not be compiled into any shipping binary. 
 * **`//impeller/entity`:** Sits one level above `//impeller/renderer` and provides a framework for building 2D renderers. Most of the pipeline state objects generated from shaders authored at build time reside in this framework. The render-pass optimization and pass-rewriting framework also resides there. This allows authoring composable 2D rendering optimizations (like collapsing passes, or, eliding them completely).
@@ -48,11 +45,8 @@ An overview of the major sub-frameworks, their responsibilities, and, relative s
 * **`//fixtures`**: Contains test fixtures used by the various test harnesses. This depends on `//flutter/testing`.
 * **`//tools`**: Contains all GN rules and python scripts for working with Impeller. These include GN rules processing GLSL shaders, including reflected shader information as source set targets, and, including compiled shader intermediate representations into the final executable as binary blobs for easier packaging.
 
-
 ## The Offline Shader Compilation Pipeline
 
-
-
 * Shaders are authored once in GLSL 4.60. This choice of shading language is consistent across all backends. Shader code resides in the Impeller source tree like any other source file.
 * At build time, the Impeller Shader Compiler (`impellerc`) converts the GLSL into SPIRV. No optimizations are performed on the generated SPIRV at this stage. This is to preserve all debugging and instrumentation information.
 * Using the SPIRV, a backend specific transpiler converts the SPIRV to the appropriate high-level shading language. This is controlled using flags to the `impellerc`.