Add support for box shadows and out-of-geometry text items with the partial renderer #7450

tronical · 2025-01-24T15:28:11Z

tronical · 2025-01-24T15:31:09Z

internal/core/item_rendering.rs

+                *data.geometry()
            }
            None => {
                let cache_entry = crate::graphics::CachedGraphicsData::new(eval);
                let geom = cache_entry.data.clone();
                rendering_data.cache_index.set(cache.insert(cache_entry));
                rendering_data.cache_generation.set(cache.generation());
-                geom.geometry
+                *geom.geometry()


This function here, filter_item in the PartialRenderer is the reason why CachedItemGeometryAndTransform needs to store not only the translation but the entire geometry of an item.

As-is in this patch, CachedItemGeometryAndTransform uses 48 bytes on aarch64. If I change this code to fetch the geometry from the item directly, then I can reduce the geometry in CachedItemGeometryAndTransform to just a translation and the size goes to 40 bytes.

I see.
I think it would be better to re-query the geometry again (untracked).
The reason filter_item returns the geometry is because it had the geometry for free. But IMHO it is better to query it again (untracked) than keeping it in the cache.

We could optimize for the common case of

Geometry == bounding rect

bounding rect is empty

tronical · 2025-01-24T15:32:42Z

Marked as draft, as I'm not entirely sure yet that this is the correct approach. It does seem to work (yay), but it increases the size of the partial renderer cache quite a bit.

I could try to extend ItemRendererFeatures with SUPPORTS_DROP_SHADOW or so and then try to shrink CachedItemGeometryAndTransform.

cc #7247

internal/core/item_rendering.rs

ogoffart · 2025-01-24T16:44:42Z

internal/core/item_rendering.rs

+                *data.geometry()
            }
            None => {
                let cache_entry = crate::graphics::CachedGraphicsData::new(eval);
                let geom = cache_entry.data.clone();
                rendering_data.cache_index.set(cache.insert(cache_entry));
                rendering_data.cache_generation.set(cache.generation());
-                geom.geometry
+                *geom.geometry()


I see.
I think it would be better to re-query the geometry again (untracked).
The reason filter_item returns the geometry is because it had the geometry for free. But IMHO it is better to query it again (untracked) than keeping it in the cache.

We could optimize for the common case of

Geometry == bounding rect

bounding rect is empty

ogoffart · 2025-01-24T16:50:16Z

internal/core/items.rs

@@ -236,6 +244,15 @@ impl Item for Empty {
    ) -> RenderingResult {
        RenderingResult::ContinueRenderingChildren
    }
+
+    fn bounding_rect_for_geometry(


(maybe documentation comment)
the other function like render uses the size instead of a geometry.
Is it because the geometry is in the parent's coordinate while render is supposed to draw in item coordinate?)

The reason why this function takes a geometry instead of a size is because the x/y can also change. That's the case with the drop shadow. Differently put: If configured accordingly, a drop shadow not only grows in direction of the x/y axis, but also in the other direction.

Should the function be called just bounding_rect?
I don't think the for_geometry adds value.

internal/core/items/image.rs

internal/core/items/text.rs

ogoffart · 2025-01-24T16:58:15Z

internal/core/items/text.rs

+        _self_rc: &ItemRc,
+        geometry: LogicalRect,
+    ) -> LogicalRect {
+        self.text_bounding_rect(window_adapter, geometry.cast()).cast()


I think that we register dependencies more than we need (eg, dependency on the text would be registed both by this call and by the render call)
dependencies cost in dependency nodes that are on the heap. We probably should make sure that bounding_rect_for_geometry is called without tracking.

You're right. For example a drop shadow's properties that affect the bounding rect are already tracked by the renderer's dirty tracker.

…king Co-authored-by: Olivier Goffart <[email protected]>

…stureHandler These don't draw anything.

…respect the bounding rect Remove the geometry field and merely store the offset/transform. This brings the size down from 40 to 32 bytes on aarch64. Related, filter_item() now respects the item's bounding rect for the decision whether to draw the item or not.

tronical · 2025-01-28T15:33:18Z

Ok, I think all the feedback is covered. I won't rebase this yet to facilitate there view, meanwhile the CI is red, but that's ok.

ogoffart

A test for the partial rendering would be nice with a shadow and some TouchArea (if the TouchArea moves it doesn't need to redraw the region)

ogoffart · 2025-01-28T18:37:45Z

internal/core/items.rs

    ) -> LogicalRect {
+        geometry.size = LogicalSize::zero();


Why not return Default::default()

ogoffart · 2025-01-28T18:40:04Z

internal/core/item_rendering.rs

@@ -485,9 +491,18 @@ pub trait ItemRenderer {
    /// Returns
    ///  - if the item needs to be drawn (false means it is clipped or doesn't need to be drawn)
    ///  - the geometry of the item
-    fn filter_item(&mut self, item: &ItemRc) -> (bool, LogicalRect) {
+    fn filter_item(


ogoffart · 2025-01-28T20:17:38Z

internal/core/item_rendering.rs

-    fn from((geometry, children_transform): (LogicalRect, Option<ItemTransform>)) -> Self {
-        Self { geometry, boxed_children_transform: children_transform.map(Into::into) }
-    }
+pub enum CachedItemGeometryAndTransform {


For the name, this caches the bounding box rather than the geometry

ogoffart · 2025-01-28T20:22:04Z

internal/core/items.rs

@@ -236,6 +244,15 @@ impl Item for Empty {
    ) -> RenderingResult {
        RenderingResult::ContinueRenderingChildren
    }
+
+    fn bounding_rect_for_geometry(


Should the function be called just bounding_rect?
I don't think the for_geometry adds value.

tronical marked this pull request as draft January 24, 2025 15:28

tronical requested a review from ogoffart January 24, 2025 15:28

Add support for box shadows with the partial renderer

88f9bdd

cc #7247

tronical force-pushed the simon/bounding-rect branch from 1d734f1 to 88f9bdd Compare January 24, 2025 15:29

tronical commented Jan 24, 2025

View reviewed changes

tronical added 2 commits January 24, 2025 17:19

Fix slint_int_coord build

891ebb8

Add support for bounding text rendering with the partial renderer

bcc176d

cc #7247

tronical changed the title ~~Add support for box shadows with the partial renderer~~ Add support for box shadows and out-of-geometry text items with the partial renderer Jan 24, 2025

ogoffart reviewed Jan 24, 2025

View reviewed changes

tronical and others added 5 commits January 28, 2025 13:45

Reduce size of CachedItemGeometryAndTransform

8296b34

Fix comment in partial renderer's filter_item() about dependency trac…

9603d7d

…king Co-authored-by: Olivier Goffart <[email protected]>

Fix bounding_rect_for_geometry for ComplexText

528b6ef

Use a zero sized bounding rect for Empty/TouchArea/FocusScope/SwipeGe…

84fa5a0

…stureHandler These don't draw anything.

ogoffart reviewed Jan 28, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for box shadows and out-of-geometry text items with the partial renderer #7450

Add support for box shadows and out-of-geometry text items with the partial renderer #7450

tronical commented Jan 24, 2025

tronical Jan 24, 2025

ogoffart Jan 24, 2025

tronical commented Jan 24, 2025

ogoffart Jan 24, 2025

ogoffart Jan 24, 2025

tronical Jan 28, 2025

ogoffart Jan 28, 2025

ogoffart Jan 24, 2025

tronical Jan 28, 2025

tronical commented Jan 28, 2025

ogoffart left a comment

ogoffart Jan 28, 2025

ogoffart Jan 28, 2025

ogoffart Jan 28, 2025

ogoffart Jan 28, 2025

Add support for box shadows and out-of-geometry text items with the partial renderer #7450

Are you sure you want to change the base?

Add support for box shadows and out-of-geometry text items with the partial renderer #7450

Conversation

tronical commented Jan 24, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tronical commented Jan 24, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tronical commented Jan 28, 2025

ogoffart left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment