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

Variable size scene encoding #152

Closed
raphlinus opened this issue Feb 21, 2022 · 0 comments · Fixed by #159
Closed

Variable size scene encoding #152

raphlinus opened this issue Feb 21, 2022 · 0 comments · Fixed by #159
Labels
architecture Changes to the way it's put together

Comments

@raphlinus
Copy link
Contributor

Right now, the main scene encoding is a sequence of fixed size draw objects. This has been the case for a while, but more recently path segments and a couple other things moved out of the scene encoding. In addition, there's a stream of Annotated objects, also fixed size, with a 1:1 correspondence to the Element objects in the scene encoding.

It would be better for it to be fully variable size, I think. That would allow larger objects (gradients come to mind) without concern for bloating the encoding of other objects that may be more compact. Here's roughly what's involved.

The main step to unlock variable size encoding is to add two more prefix sums to the draw monoid: these count byte (or possibly u32) offsets within the element stream, and also a new variable size object to take the place of "annotated." Most of the functionality of Annotated moves to other places. The bounding box gets its own stream (this is generally a move towards SoA). anything currently just copied from Element is replaced by a read from the scene buffer (there's no value in copying it; this was originally seen as a simplification, so the memory read patterns were more uniform). The main thing that remains is the line equation for linear gradients (and a similar computation for radial gradients, when that's done).

There's nothing particularly deep about these changes. They follow the same general pattern as the element pipeline changes. Also there should be cleanup involved, the Rust-side encoding will I think no longer use piet-gpu-derive at all, and in general that could be removed.

@raphlinus raphlinus added the architecture Changes to the way it's put together label Feb 21, 2022
raphlinus added a commit that referenced this issue Mar 11, 2022
WIP - this passes the tests but rendering is still questionable.

Closes #152
raphlinus added a commit that referenced this issue Mar 14, 2022
This patch switches to a variable size encoding of draw objects.

In addition to the CPU-side scene encoding, it changes the representation of intermediate per draw object state from the `Annotated` struct to a variable "info" encoding. In addition, the bounding boxes are moved to a separate array (for a more "structure of "arrays" approach). Data that's unchanged from the scene encoding is not copied. Rather, downstream stages can access the data from the scene buffer (reducing allocation and copying).

Prefix sums, computed in `DrawMonoid` track the offset of both scene and intermediate data. The tags for the CPU-side encoding have been split into their own stream (again a change from AoS to SoA style).

This is not necessarily the final form. There's some stuff (including at least one piet-gpu-derive type) that can be deleted. In addition, the linewidth field should probably move from the info to path-specific. Also, the 1:1 correspondence between draw object and path has not yet been broken.

Closes #152
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
architecture Changes to the way it's put together
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant