Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Scatterbrain README tweaks #44

Merged
merged 2 commits into from
Nov 26, 2024
Merged

chore: Scatterbrain README tweaks #44

merged 2 commits into from
Nov 26, 2024

Conversation

Jarbuckle
Copy link
Contributor

Scatterbrain README tweaks

What

After reading through the README for the first time, I thought there were a few parts that could be adjusted to aid readability and understandability. Also various minor spelling and grammar items caught my eye.

How

  • Adjusted some of the phrasing/wording for readability/comprehension in Scatterbrain README.md
  • Fixed some typos/grammatical items in Scatterbrain README.md

PR Checklist

  • Is your PR title following our conventional commit naming recommendations?
  • Have you filled in the PR Description Template?
  • Is your branch up to date with the latest in main?
  • Do the CI checks pass successfully?
  • Have you smoke tested the example applications?
  • Did you check that the changes meet accessibility standards?
  • Have you tested the application on these browsers?
    • Chrome (Fully supported)
    • Firefox (Major bug fixes supported)
    • Safari (Major bug fixes supported)

Copy link
Collaborator

@lanesawyer lanesawyer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the polish! I especially love the backtick stuff on code types and whatnot. Thanks for reading through this to learn more about the library and for giving it an upgrade!


Lets start with scheduling first. Our goal is to be able to call the function `buildAsyncRenderer` from `async-frame.ts`. Its signature is thus:
`function buildAsyncRenderer<Dataset, Item, Settings, SemanticKey extends string, CacheKeyType extends string, GpuData extends Record<SemanticKey, ReglCacheEntry>>(renderer: Renderer<Dataset, Item, Settings, GpuData>)`
> `function buildAsyncRenderer<Dataset, Item, Settings, SemanticKey extends string, CacheKeyType extends string, GpuData extends Record<SemanticKey, ReglCacheEntry>>(renderer: Renderer<Dataset, Item, Settings, GpuData>)`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Double-checked, this signature is still correct! 🎉

5. `cacheKey` - the cache system needs to know how to uniquely identify any data it fetches. What makes sense here will depend on your data entirely. Make sure this is a pure function of its input!
6. `destroy` - if you allocated (excluding cache data!) any resources, particularly GPU resources, you can release them here, think lookup tables or textures, etc.
1. `getVisibleItems`, when given a `Dataset` and `Settings`, returns an array of Items that are in view. After all, the first step of any good renderer is knowing the minimum amount of work to do! Given this, your application's "Camera" -- whatever form that may take -- should be represented in your `Settings` object.
2. `fetchItemContent`, when given a single `Item` (and `Dataset` and `Settings`, of course), returns functions that fetch the raw, renderable data that an `Item` represents. In many cases, this could be very simple: for example, `return {pixels: ()=>${dataset.url}/${item.path}.jpg}` would be quite reasonable! This interface is shaped to support "columnar" data: imagine rows in a database describing cells, where the columns of the table contain X and Y positions, and perhaps colors or other measurements. In this analogy, an `Item` is a group of rows of the table, and what is returned would be a `SELECT` of each column of interest to the renderer.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this all looks nice! thanks for fixing my words! re-reading this, I think a visual example of what I mean by columnar data would be helpful here

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yeah, that probably would help with clarity!

@Jarbuckle Jarbuckle merged commit 566f17a into main Nov 26, 2024
5 checks passed
@Jarbuckle Jarbuckle deleted the joel/readme-updates branch November 26, 2024 18:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants