Add support for CSS conic-gradient 'from <angle>' syntax #9830

task-jp · 2025-10-23T14:07:44Z

Summary

Implements rotation support for conic gradients by adding the CSS-standard from <angle> syntax, which rotates the entire gradient by the specified angle.

Syntax

@conic-gradient(from 90deg, red 0deg, blue 180deg, red 360deg)

ogoffart

What's the motivation behind this.

It looks like this makes Slint different from what the CSS spec says.

tests/screenshots/references/software/basic/conic-gradients.png

task-jp · 2025-10-24T15:05:18Z

Thanks for your review.

What's the motivation behind this.

In https://snapshots.slint.dev/master/editor/index.html?load_url=https://raw.githubusercontent.com/slint-ui/slint/master/examples/speedometer/demo.slint, CarButton tries to rotate angles in @conic-gradients when it is pressed. To solve this, I thought it would be good to support any degrees.

this makes Slint different from what the CSS spec says.

Right. should we introduce the [ from [ <angle> | <zero> ] ]? for such usecase?

ogoffart · 2025-10-24T15:29:35Z

I see. I can achieve the desired effect with

@conic-gradient( #020414 stop4 - 1turn, #ff0000 stop5 - 1turn, #000000 stop6 - 1turn, #020414 stop1, #ff0000 stop2, #020414 stop3, #020414 stop4, #ff0000 stop5, #000000 stop6);

I added stop4 to stop6 back at the beginning with a - 1turn
So when some value are more than 360deg, they don't wrap around, but the value before that wraps around.

I would prefer keeping close to the CSS spec for gradients.

Implement rotation support for conic gradients by adding the 'from <angle>' syntax, which rotates the entire gradient by the specified angle. - Add `from_angle` field to ConicGradient expression - Parse 'from <angle>' syntax in compiler (defaults to 0deg when omitted) - Normalize angles to 0-1 range (0.0 = 0°, 1.0 = 360°) - Add `ConicGradientBrush::rotated_stops()` method that: * Applies rotation by adding from_angle to each stop position * Adds boundary stops at 0.0 and 1.0 with interpolated colors * Handles stops outside [0, 1] range for boundary interpolation - Update all renderers (Skia, FemtoVG, Qt, Software) to use rotated_stops() The rotation is applied at render time by the rotated_stops() method, which ensures all renderers consistently handle the gradient rotation.

ogoffart

Nice! thank you very much.

This looks quite good to me.

I'm just wondering what you think about the idea to normalize the gradient brush at construction time instead of every time it is used.

docs/astro/src/content/docs/reference/colors-and-brushes.mdx

internal/core/graphics/brush.rs

ogoffart · 2025-10-30T10:25:20Z

internal/core/graphics/brush.rs

+    ///
+    /// This is useful when you need to work with the actual visual positions of the stops
+    /// after the gradient has been rotated.
+    pub fn rotated_stops(&self) -> alloc::vec::Vec<GradientStop> {


Shouldn't we be storing them like this instead of re-allocating a new vector every time we want to draw?

When from is not set, we can use the vector prepared in new(). In case of with from, we can pass the vector to backends as it is. However, (all?) backend that doesn't support angles < 0 and > 1 needs to do the conversion.

But why don't we compute that in new already since new already knows from?

ogoffart · 2025-10-30T10:26:59Z

internal/core/graphics/brush.rs

+    }
+
+    /// Helper: Linearly interpolate between two colors
+    fn interpolate_color(c1: Color, c2: Color, t: f32) -> Color {


Is this different from Color::mix ?

The CSS gradient spec uses simple linear interpolation between color stops. The gradient line’s color is interpolated between the colors of the two color stops, with the interpolation taking place in premultiplied RGBA space. premultiplied is not implemented in the interpolate_color yet.
https://www.w3.org/TR/css-images-3/#coloring-gradient-line

Color::mix implements the Sass color mixing algorithm, which applies alpha-weighted blending.
https://github.com/sass/sass/blob/47d30713765b975c86fa32ec359ed16e83ad1ecc/spec/built-in-modules/color.md#mix

Without alpha, no difference. with alpha, there is difference. Do you think Color should support two mix methods?

The code of Color::mix is maybe a bit hard to read. But I think the reason is that when we go from, say #ffff to #f001, this should go from white to slightly red, but it shouldn't show the red too much.

This example illustrate the difference: slintpad

Now I must say that i haven't compared the functions implementation much, but your implementation here is not in premultiplied space.
But if you say that Color::mix doesn't work for this, so be it.

Wraps the rotated conic gradient example in CodeSnippetMD to automatically generate and display a visual screenshot of the gradient rotation effect. This makes it easier for users to understand how the 'from' parameter rotates the gradient.

The from_angle and stops fields don't need to be pub since: - Rust code in the same module can access them without pub - C++ FFI access works through cbindgen-generated struct (C++ struct members are public by default)

- Changed return type from Vec to SharedVector - When from_angle is zero, returns a clone of internal SharedVector (only increments reference count instead of allocating new Vec) - Removed break from duplicate position separation loop to handle all duplicate pairs, not just the first one - Updated documentation to match actual implementation

- CSS conic-gradient does not automatically sort color stops - Stops are processed in the order specified by the user - Changed boundary stop interpolation logic to use max_by/min_by instead of relying on sorted order - This allows CSS-style hard transitions when stops are out of order

ogoffart · 2025-10-31T08:29:48Z

internal/core/graphics/brush.rs

+    /// The `from_angle` parameter is in normalized form (0.0 = 0°, 1.0 = 360°), corresponding
+    /// to CSS's `from <angle>` syntax. It rotates the entire gradient clockwise.
+    pub fn new(from_angle: f32, stops: impl IntoIterator<Item = GradientStop>) -> Self {


For consistency with LinearGradientBrush::new, i think the angle should be specified in degrees.
In Slint, angles are always degrees.

ogoffart · 2025-10-31T08:34:25Z

internal/core/graphics/brush.rs

            }
-            Brush::ConicGradient(g) => {
-                Brush::ConicGradient(ConicGradientBrush::new(g.stops().map(|s| GradientStop {
+            Brush::ConicGradient(g) => Brush::ConicGradient(ConicGradientBrush::new(


Since this touches only the colors, and not the stops, this could just map the colors without having to re-normalize thing.
This doesn't have to be done in this PR, but we could imagine a (internal) Brush::visit_colors(&mut self, map: impl Fn(&mut Color)) and so one could implement brighter, darker, with_alpha and transparentize using it. But anyway, this can be done independently.

ogoffart · 2025-10-31T08:50:45Z

internal/core/graphics/brush.rs

+    }
+
+    /// Helper: Linearly interpolate between two colors
+    fn interpolate_color(c1: Color, c2: Color, t: f32) -> Color {


The code of Color::mix is maybe a bit hard to read. But I think the reason is that when we go from, say #ffff to #f001, this should go from white to slightly red, but it shouldn't show the red too much.

This example illustrate the difference: slintpad

Now I must say that i haven't compared the functions implementation much, but your implementation here is not in premultiplied space.
But if you say that Color::mix doesn't work for this, so be it.

ogoffart · 2025-10-31T09:09:13Z

internal/core/graphics/brush.rs

+    ///
+    /// This is useful when you need to work with the actual visual positions of the stops
+    /// after the gradient has been rotated.
+    pub fn rotated_stops(&self) -> alloc::vec::Vec<GradientStop> {


But why don't we compute that in new already since new already knows from?

ogoffart reviewed Oct 24, 2025

View reviewed changes

tests/screenshots/references/software/basic/conic-gradients.png Show resolved Hide resolved

task-jp force-pushed the conic-gradients-rotation branch from 1a156d1 to 578faaf Compare October 30, 2025 09:43

task-jp changed the title ~~Support arbitrary angle ranges in conic-gradient~~ Add support for CSS conic-gradient 'from <angle>' syntax Oct 30, 2025

task-jp force-pushed the conic-gradients-rotation branch from 5a02287 to 820ae2b Compare October 30, 2025 09:58

ogoffart reviewed Oct 30, 2025

View reviewed changes

task-jp added 4 commits October 31, 2025 08:56

Make ConicGradientBrush fields private

0b41b24

The from_angle and stops fields don't need to be pub since: - Rust code in the same module can access them without pub - C++ FFI access works through cbindgen-generated struct (C++ struct members are public by default)

task-jp force-pushed the conic-gradients-rotation branch from 2a5b848 to daabee4 Compare October 31, 2025 01:35

[autofix.ci] apply automated fixes

fdcabb4

ogoffart reviewed Oct 31, 2025

View reviewed changes

Add support for CSS conic-gradient 'from <angle>' syntax #9830

Are you sure you want to change the base?

Add support for CSS conic-gradient 'from <angle>' syntax #9830

Conversation

task-jp commented Oct 23, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Syntax

Uh oh!

ogoffart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

task-jp commented Oct 24, 2025

Uh oh!

ogoffart commented Oct 24, 2025

Uh oh!

ogoffart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

task-jp Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

task-jp Oct 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

task-jp commented Oct 23, 2025 •

edited

Loading

task-jp Oct 31, 2025 •

edited

Loading

task-jp Oct 31, 2025 •

edited

Loading