Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,6 +24,7 @@ This release has an [MSRV] of 1.82.

### Changed

- Breaking change: Added `PlusDarker` variant to `Compose` ([#112][] by [@sagudev][])
- Breaking change: `Image` has been renamed to `ImageBrush`, which now consists of an `ImageData` and an `ImageSampler`. ([#117][], [#123][] by [@nicoburns][], [@DJMcNab][])
- Breaking change: `Font` has been renamed to `FontData` to match `ImageData`. ([#126][] by [@nicoburns][])
- Breaking change: the angle directions of `SweepGradientPosition` are now described to be clockwise in a Y-down coordinate system, as is common in computer graphics.
Expand Down Expand Up @@ -152,6 +153,7 @@ This release has an [MSRV] of 1.70.
[#95]: https://github.com/linebender/peniko/pull/95
[#103]: https://github.com/linebender/peniko/pull/103
[#104]: https://github.com/linebender/peniko/pull/104
[#112]: https://github.com/linebender/peniko/pull/112
[#114]: https://github.com/linebender/peniko/pull/114
[#115]: https://github.com/linebender/peniko/pull/115
[#117]: https://github.com/linebender/peniko/pull/117
Expand Down
6 changes: 6 additions & 0 deletions src/blend.rs
Original file line number Diff line number Diff line change
Expand Up @@ -91,6 +91,12 @@ pub enum Compose {
/// Allows two elements to cross fade by changing their opacities from 0 to 1 on one
/// element and 1 to 0 on the other element.
PlusLighter = 13,
/// The behavior of this mode is currently not exactly defined,
/// as spec discussions are still ongoing [w3c/fxtf-drafts#447],
/// but it's present here to prevent future breaking changes.
///
/// [w3c/fxtf-drafts#447](https://github.com/w3c/fxtf-drafts/issues/447)
Comment on lines +94 to +98
Copy link
Member

Choose a reason for hiding this comment

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

What do you think of a statement like:

/// The upstream specification of this blend mode is not well-formed, and so we 
/// cannot recommend using it at present. See the discussion in [w3c/fxtf-drafts#447].
/// This blend mode is currently only implemented on the web by Safari, and is currently 
/// provided only for compatibility with rendering on Apple platforms.
/// As such, we define this mode as described in [David Baron's comment in that issue][comment].
/// However, this implementation is potentially disputed, and so we expect that it might change.
///
/// [comment]: https://github.com/w3c/fxtf-drafts/issues/447#issuecomment-1699293766

I feel that the current comment is both too vague for end-users, and too vague for renderer implementers.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree with discouragement message, but I purposefully wrote vague message so we can let render implementers define what plusdarker does (so that it is implementation defined).

Anyway given that this will be deferred to next breaking peniko release (along with mix clip stuff), maybe we can check which formula is actually implemented on apple.

Copy link
Member

Choose a reason for hiding this comment

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

@dbaron if you're willing to confirm whether w3c/fxtf-drafts#447 (comment) is still the best source (externally to Apple) for implementing plus-darker as a renderer, that would be very helpful here.

so we can let render implementers define what plusdarker does (so that it is implementation defined).

Can you clarify why? To me, that seems like the worst of all worlds:

  • If we do change to define it exactly, that then has to go into a breaking change anyway.
  • Any renderer is going to implement it as specified in the comment I linked, as that is the most up-to-date source (as far as I'm aware).
  • We want the Vello renderers to have the same rendering outputs (barring epsilon difference), which this not being well-defined doesn't facilitate.

In terms of the underlying principles to reach these conclusions, I can see why you'd reach this conclusion if you thought that the formula is extremely likely to change from the one provided in the linked comment (which is currently 2 years old). I think that to be unlikely (if nothing else, based on the Lindy effect), so think defining it exactly is low-risk and is very advantageous.

Copy link

Choose a reason for hiding this comment

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

@dbaron if you're willing to confirm whether w3c/fxtf-drafts#447 (comment) is still the best source (externally to Apple) for implementing plus-darker as a renderer, that would be very helpful here.

Yeah, I think it is. I haven't had the chance to finish up what I was supposed to do to clean up the spec there, though...

PlusDarker = 14,
// NOTICE: If a new value is added, be sure to modify `MAX_VALUE` in the bytemuck impl.
}

Expand Down
4 changes: 2 additions & 2 deletions src/impl_bytemuck.rs
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ unsafe impl bytemuck::checked::CheckedBitPattern for Compose {
unsafe impl bytemuck::Contiguous for Compose {
type Int = u8;
const MIN_VALUE: u8 = Self::Clear as u8;
const MAX_VALUE: u8 = Self::PlusLighter as u8;
const MAX_VALUE: u8 = Self::PlusDarker as u8;
}

// Safety: The enum is `repr(u8)` and has only fieldless variants.
Expand Down Expand Up @@ -223,7 +223,7 @@ mod tests {

#[test]
fn contiguous() {
let compose1 = Compose::PlusLighter;
let compose1 = Compose::PlusDarker;
let compose2 = Compose::from_integer(compose1.into_integer());
assert_eq!(Some(compose1), compose2);

Expand Down
Loading