linebender / peniko Goto Github PK

With the added serde derives, in PR #26 it came up on zulip that the serialization of images is "not ideal", but useful enough to keep for now but might eventually require a breaking change.

The general issue is that Image Blobs may be shared, which when serialized will duplicate the data.
This then deserializes to multiple images each having their own unique ID.

serde

The most relevant issue I found in serde is the following involving the serde_state crate
which adds on top of serde SerializeState and DeserializeState traits, alas this is an experimental fork of serde
which is not in the maintenance goldilocks zone at 110 commits ahead and 745 commits behind serde itself.

serde-rs/serde#881

I guess my recommendation for the current state would be if serializing shared images serialize them to a map/vector
and reference those by key or index.

Alternatives to serde

Rkyv by default does the right thing for serializing shared pointers
It isn't really comparable to serde though in that it is a fixed data format rather than a data model supporting multiple data formats.

I think it might be more ideal, because it would be both zero copy, and we don't have to work around the data model to avoid duplicating shared references.

There is one issue which gives me some pause, that I would probably want to fix/work on before integrating it rkyv/rkyv#285 because rkyv serializes enum variants by their representation value rather than nominally. Simply reordering enums or adding variants that aren't appended to the current variants can cause compatibility hazards.

In Velato, there's a section @dfrg wrote stating we should move logic to peniko to allow alpha factors for brushes.

// TODO: probably move this to peniko. The better option is to add an alpha
// parameter to the draw methods in vello. This is already handled at the
// encoding level.
pub(crate) fn brush_with_alpha(brush: &Brush, alpha: f64) -> Brush {
    if alpha == 1.0 {
        brush.clone()
    } else {
        match brush {
            Brush::Solid(color) => color.with_alpha_factor(alpha as f32).into(),
            Brush::Gradient(gradient) => Brush::Gradient(peniko::Gradient {
                kind: gradient.kind,
                extend: gradient.extend,
                stops: gradient
                    .stops
                    .iter()
                    .map(|stop| stop.with_alpha_factor(alpha as f32))
                    .collect(),
            }),
            _ => unreachable!(),
        }
    }
}

Just came to say that I think this is a cool project that solves a real problem - there have been a few times where I've wanted things like a Color type but don't want to pull in all of piet.

One note - I would at least disable rewriting history (force push) and delete on the main branch.

The concepts behind the Mix, Compose and Fill types are well-known in computer graphics, but they're not intuitive for a newcomer and hard to explain through text. (And even a experience developer might not remember which is which.)

We should probably edit their respective doc comments to add links to pages illustrating the underlying concepts. We can probably find good resources on MDN or Wikipedia.

Have you considered publishing Peniko to crates.io? Since crates.io does not support Git dependencies, publishing Peniko would enable crates that depend on Peniko to publish as well.