Migrate to using raw_resource_handle

[waywardmonkeys]

No description provided.

[waywardmonkeys]

Before this can land, I think 3 things need to happen, at least:

• The crate should be published and we don't add another git dependency.
• We decide whether or not that crate should add a serde feature or we remove the serde support from Image in this crate, which I guess would propagate outward and include removing it from Brush as well.
• We think about adding a different type bound on the contstructor Image::new and maybe some additional From impls on Blob so that creating an image doesn't necessarily have to know about Blob (but can create one automatically).

This needs feedback from @dfrg at a minimum.

[waywardmonkeys]

Some previous discussion of serde in #30.

[ratmice]

As far as point 2, I've definitely been using serialize on peniko::Brush, none of my programs ever construct the Brush::Image variant though it is exposed from the library, selvage::PaintOp

That library code however mostly provides (the trait) for a thin layer around vello::Scene, and the Scene::Stroke and Fill, in vello, both take BrushRef and thus potentially images.

As we discussed on zulip though, I think I should be able to use serialize_with for that enum in selvage::PaintOp
should we remove it from peniko. I only recently got it working all together with all the crate versions coming into alignment, but it isn't the worst thing to go back to git versions, and [patch] sections if necessary too.

In that library though, my preference is definitely to keep things relatively similar to the Scene API but that does like in this case bring with it these variants of brush I'm not actually using.

[dfrg]

My general thought on this is that we should carefully consider what raw_resource_handle should look like rather than just extracting the current design and adding a dependency immediately.

Just a few potential questions:

1. Should we disconnect blob and identifier? I feel like shared unique ids are the most important concept. We may want to support resources that are not represented as raw bytes.
2. Maybe separate the id space by type rather than having one shared by all resources?
3. Should blob also support &'static [T] to handle embedded data?
4. Should blob have an associated range to support suballocated resources (potentially from mmaped files?)

And probably others that I haven’t considered.

[waywardmonkeys]

@dfrg That's exactly the conversations that I want to kick off. There kept being requests to start down this path, but we needed to take the first step.

I don't really think this is something that will happen for the December set of releases. (I have very little time for it myself and my focus is elsewhere in the stack.)

[nicoburns]

Would it be crazy to make the identity aspect a trait instead of (or as well as) as type? Then something like Font could be usize smaller by packing the index and id into 64 bits...

[ratmice]

We decide whether or not that crate should add a serde feature or we remove the serde support from Image in this crate, which I guess would propagate outward and include removing it from Brush as well.

@waywardmonkeys it occurred to me that since Serialize returns a Result we could just stop supporting serialization for the Image variant of Brush. It looks like we can just use the skip_serializing + skip_deserializing variant attributes from the serde_derive macros for that...

something like:

#[derive(Clone, Debug, PartialEq)]
#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
pub enum Brush {
    /// Solid color brush.
    Solid(AlphaColor<Srgb>),
    /// Gradient brush.
    Gradient(Gradient),
    /// Image brush.
   #[serde(skip_serializing, skip_deserializing)]
    Image(Image),
}