Performance notes

src/SUMMARY.md

@@ -15,6 +15,7 @@
 - [Debugging](debugging/README.md)
     - [GDB]()
     - [Logging]()
+    - [Automated Tests]()
     - [Performance Profiling]()
 
 # User Guide

src/development/README.md

@@ -46,6 +46,7 @@ A thorough series of steps might be:
 5. Read the [RISC-V Guide](https://github.com/mikeroyal/RISC-V-Guide)/[RISC-V Bytes](https://danielmangum.com/categories/risc-v-bytes/) to learn more about the **RISC-V** architecture
 6. Read the OSDev Wiki entries on [Microkernels](https://wiki.osdev.org/Microkernel) and [Message Passing](https://wiki.osdev.org/Message_Passing)
 7. Read the [Async Book](https://rust-lang.github.io/async-book/01_getting_started/01_chapter.html)
+8. [This](https://sled.rs/perf.html) has some good information about performance
 
 Additionally you might want to learn about **Vulkan** if you're going to be hacking on the [GUI](/development/design/gui.md):
 1. Go through the [Vulkan Tutorial (Rust)](https://kylemayes.github.io/vulkanalia/introduction.html) to learn some of the basics

src/development/design/README.md

@@ -33,7 +33,7 @@ Further design decisions are gone into detail in the next few chapters.
 These names and layout are all **WIP**.
 ```
 
-All of the code will take place in seperate repositories.
+All of the code will take place in separate repositories.
 Information on actually commiting, pulling, etc. is in the [Workflow](/development/workflow.md) chapter.
 
 Most of the code will be implemented as libraries, enabling for them to be used across systems, and worked on separately.

src/development/design/gui.md

@@ -2,9 +2,17 @@
 Eventually, programs will be able to use the `photon` library to have access to a graphics API.
 This will initialize various [actors](/development/design/actor.md) to represent parts of the UI.
 
+## Performance
+The **GUI** is one of the systems where latency is far more important than throughput.
+There are several things that aid with performance of this system:
+1. Each window is drawn in a separate buffer, allowing for easy concurrency
+3. Messages use the [latency bus](/development/design/actor.md#latency)
+3. All draws are based on optimized and simple low-level operations
+4. Only changes are re-rendered
+
 ## Drawing
 When a **GUI** element wants to update, it first sends a [message](/development/design/actor.md#messages) to the `kernel`.
-The `kernel` then calculates the overlaying of each window, writes each window to it's own buffer, then updates the screen buffer with ones that have changed, which is then drawn to the screen.
+The `kernel` then calculates the overlaying of each window, writes each window to its own buffer, then updates the screen buffer with ones that have changed, which is then drawn to the screen.
 This ensures that only necessary parts are re-rendered, and the rendering can be done asynchronously/threaded.
 
 The `photon` library will not only provide a high-level API for applications to use, but also lower-level drawing methods for the `kernel` to use.