Add experimental plumbing for hardware accelerated rendering operations with the software renderer #7685

tronical · 2025-02-20T16:44:13Z

No description provided.

…t buffers in a synchronous way

…or background draw

…ture instead of many arguments

…egral angle

tronical · 2025-02-20T16:45:18Z

cc @scristall-bennu @0x6e

api/cpp/include/slint-platform.h

…for Rgb565Pixel

internal/core/software_renderer.rs

ogoffart · 2025-02-20T17:40:28Z

internal/core/software_renderer.rs

@@ -82,7 +80,7 @@ impl RenderingRotation {
        matches!(self, Self::Rotate90 | Self::Rotate180)
    }
    /// Angle of the rotation in degrees
-    fn angle(self) -> f32 {
+    pub fn angle(self) -> f32 {


This adds public API. Is that on purpose?
This is a non-exhaustive enum, would angle work with any possible future value we can imagine? (for example rotation around another axis or transpose)
should the function signature somehow specify it is in degree and not radians or something else?
If in doubt, we can always use pub(crate)

Ah yes. It can't be pub(crate) because it's accessed from the cpp crate, but I can work around it and duplicate this function, alternatively. I think the signature and docs are fine as-is, but I can do the workaround if you prefer.

internal/core/software_renderer.rs

ogoffart · 2025-02-20T17:48:06Z

internal/core/software_renderer.rs

                renderer.actual_renderer.processor.dirty_region = dirty_region.clone();
+                renderer.actual_renderer.processor.process_rectangle(


Note that the original code should fill the background and not blend it.
That is, if the background is transparent, we need to end up with transparent pixels in the pixel buffer. (as opposed to whatever was in the pixel buffer before)
It is my impression that process_rectangle will blend into what's currently in the buffer.

(That makes a difference if the target pixel is ARGB, which is possible with winit software)

Ah yes, indeed. I'll add a composition mode to handle this.

I've tried to implement this now, but there's a caveat/question, see process_rectangle_impl.

ogoffart · 2025-02-20T18:01:53Z

internal/core/software_renderer.rs

+    ) {
+        let mut line = geometry.min_y();
+        while let Some(mut next) =
+            region_line_ranges(&self.dirty_region, line, &mut self.dirty_range_cache)


region_line_ranges tries to split the ranges so that they span on lines. for the line by line rendering.
But here, i think it would be wiser to simply iterate over the rectangle in the region. I think they shouldn't overlap.

Example:
Imagine the following dirty region

+----+ +----+ | A | | B | | | +----+ | | +----+

This will then generate a region for the upper part of A, B, and the lower part of A.
But it'd be better to "simply" draw A, then B. Not?

Sounds good to me.

I hope I understood this correctly and applied this to rectangle and texture fills.

I don't think you understood.
My point was that, in this funciton, instead of calling region_line_ranges, just call self.dirty_region.iter_box(), but the rectangles can overlap so that is not a good idea.

There's no need to split the areas to span lines.

…ate module

Don't blend the background but fill it when going through ProcessScene.

tronical · 2025-02-21T10:10:58Z

internal/core/software_renderer.rs

+                    match composition_mode {
+                        CompositionMode::Source => buffer.line_slice(l as usize)
+                            [begin as usize..end as usize]
+                            .fill(<T as TargetPixel>::from_rgb(color.red, color.green, color.blue)),


This doesn't seem entirely correct to me, as it doesn't copy over the alpha and it doesn't divide the pre-multipled alpha.

Should I add a fill_slice() to TargetPixel, similar to blend_slice?

Right, this is not correct as this loses the alpha.

You can do what was done before:

let mut bg = T::background(); T::blend(&mut bg, color); buffer.line_slice(/*...*/)[/*...*/].fill(bg)

But adding a fill_slice would also work, i guess.

ogoffart · 2025-02-21T11:17:50Z

internal/core/software_renderer.rs

    dirty_range_cache: Vec<core::ops::Range<i16>>,
    dirty_region: PhysicalRegion,
 }

-impl<T: TargetPixel> RenderToBuffer<'_, T> {
+impl<T: TargetPixel, B: target_pixel_buffer::TargetPixelBuffer<Pixel = T>> RenderToBuffer<'_, B> {


Do we need T?
Can it be done with

Suggested change

impl<T: TargetPixel, B: target_pixel_buffer::TargetPixelBuffer<Pixel = T>> RenderToBuffer<'_, B> {

impl<B: target_pixel_buffer::TargetPixelBuffer> RenderToBuffer<'_, B> {

And then use P::Pixel instead of T

Excellent idea. Done :)

internal/core/software_renderer.rs

ogoffart · 2025-02-21T11:32:27Z

internal/core/software_renderer.rs

+                    match composition_mode {
+                        CompositionMode::Source => buffer.line_slice(l as usize)
+                            [begin as usize..end as usize]
+                            .fill(<T as TargetPixel>::from_rgb(color.red, color.green, color.blue)),


Right, this is not correct as this loses the alpha.

You can do what was done before:

let mut bg = T::background(); T::blend(&mut bg, color); buffer.line_slice(/*...*/)[/*...*/].fill(bg)

But adding a fill_slice would also work, i guess.

ogoffart · 2025-02-21T11:50:11Z

internal/core/software_renderer.rs

-                extra_right_clip,
-            );
-        });
+        if !self.buffer.draw_texture(


That was better before. If you are not passing the dirty region to the function, how is it going to clip for the dirty region?
So I see two possibility:

Put pack the call to draw_texture within foreach_region

Or pass the dirty region to the draw_texture function and let the implementer do the clipping.

I'd think 1. is the most convenient, unless there is a way to do hardware clip, but i don't think that's the case on most hardware i know.

👍 I reverted back to 1.

internal/core/software_renderer.rs

ogoffart · 2025-02-21T11:53:50Z

internal/core/software_renderer.rs

+            self.foreach_region(&geometry, |buffer, rect, extra_left_clip, extra_right_clip| {
+                let begin = rect.min_x();
+                let end = rect.max_x();
+                for l in rect.min_y()..rect.max_y() {


that's just foreach_ranges

internal/core/software_renderer/target_pixel_buffer.rs

ogoffart · 2025-02-21T11:56:52Z

internal/core/software_renderer/target_pixel_buffer.rs

+        _color: PremultipliedRgbaColor,
+        _composition_mode: CompositionMode,
+    ) -> bool {
+        false


instead of returning bool, we could make the default implementation call the fallback.
But then the implementer has no way to call the fallback only in some cases. so i guess it's good the way you did it.

That was my thinking, too.

This reverts commit 43bccd9.

tronical · 2025-02-21T20:11:03Z

I hope I addressed all feedback. There's the open question about the angle() function: I'm happy to go either way, make it public or not. Let me know what you prefer.

tronical requested a review from ogoffart February 20, 2025 16:44

tronical and others added 10 commits February 20, 2025 17:44

WIP: Add plumbing for acceleration pixel blending operations on targe…

8fd6921

…t buffers in a synchronous way

WIP: Start wrapping TargetPIxelBuffer in C++

580cc3a

Add draw_texture/process_texture and use accelerated fill_rectangle f…

612cdf9

…or background draw

Add span_y to draw_texture to fix partial texture draws

40b7820

Change TargetPixelBuffer's draw_texture function to take a data struc…

4d2e980

…ture instead of many arguments

Expose screen rotation in the TargetPixelBuffer's draw_texture as int…

a33605a

…egral angle

Fix the build with the experimental feature turned off

8d17ad8

Some C++ docs for TargetPixelBuffer

bd3c11f

Improve API for C++ TargetPixelBuffer::draw_texture's blending color

d2edf05

Missing docs fix

1694349

tronical force-pushed the simon/hwaccel branch from 1b49750 to 1694349 Compare February 20, 2025 16:45

More docs

64764df

scristall-bennu reviewed Feb 20, 2025

View reviewed changes

api/cpp/include/slint-platform.h Outdated Show resolved Hide resolved

[autofix.ci] apply automated fixes

e4b143e

scristall-bennu reviewed Feb 20, 2025

View reviewed changes

api/cpp/include/slint-platform.h Show resolved Hide resolved

tronical added 2 commits February 20, 2025 19:00

Fix invalid reinterpret_cast in render to target pixel buffer method …

b72c507

…for Rgb565Pixel

Fix docs about fixed point format for source texture offsets

06db589

ogoffart reviewed Feb 20, 2025

View reviewed changes

Fix build for C++ generated code for embedded textures

dc214ab

tronical force-pushed the simon/hwaccel branch from eb7a665 to dc214ab Compare February 20, 2025 18:10

tronical added 3 commits February 21, 2025 10:09

Simplify accelerated texture and rectangle fills

43bccd9

There's no need to split the areas to span lines.

Separate the target pixel buffer trait and related types into a separ…

1e6e1cf

…ate module

Fix window background fill

2a33efd

Don't blend the background but fill it when going through ProcessScene.

tronical commented Feb 21, 2025

View reviewed changes

ogoffart reviewed Feb 21, 2025

View reviewed changes

tronical added 3 commits February 21, 2025 15:24

Simplify background color passing

59b6747

Prospective fix for background fill

dce2900

Revert "Simplify accelerated texture and rectangle fills"

3e22d7d

This reverts commit 43bccd9.

tronical added 3 commits February 21, 2025 21:03

Rename TargetPixelBuffer::Pixel to ::TargetPixel

eee61ab

Simplify RenderToBuffer declaration

44d5690

Simplify foreach_ranges by re-using foreach_region

d832e76

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add experimental plumbing for hardware accelerated rendering operations with the software renderer #7685

Add experimental plumbing for hardware accelerated rendering operations with the software renderer #7685

tronical commented Feb 20, 2025

tronical commented Feb 20, 2025

ogoffart Feb 20, 2025

tronical Feb 20, 2025

ogoffart Feb 20, 2025

tronical Feb 21, 2025

tronical Feb 21, 2025

ogoffart Feb 20, 2025

tronical Feb 20, 2025

tronical Feb 21, 2025

ogoffart Feb 21, 2025

tronical Feb 21, 2025

ogoffart Feb 21, 2025

ogoffart Feb 21, 2025

tronical Feb 21, 2025

ogoffart Feb 21, 2025

ogoffart Feb 21, 2025

tronical Feb 21, 2025

ogoffart Feb 21, 2025

ogoffart Feb 21, 2025

tronical Feb 21, 2025

tronical commented Feb 21, 2025

		renderer.actual_renderer.processor.dirty_region = dirty_region.clone();
		renderer.actual_renderer.processor.process_rectangle(

	impl<T: TargetPixel, B: target_pixel_buffer::TargetPixelBuffer<Pixel = T>> RenderToBuffer<'_, B> {
	impl<B: target_pixel_buffer::TargetPixelBuffer> RenderToBuffer<'_, B> {

Add experimental plumbing for hardware accelerated rendering operations with the software renderer #7685

Are you sure you want to change the base?

Add experimental plumbing for hardware accelerated rendering operations with the software renderer #7685

Conversation

tronical commented Feb 20, 2025

tronical commented Feb 20, 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

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

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

Choose a reason for hiding this comment

tronical commented Feb 21, 2025