wlr_render_rect improvement proposal

[icedman]

This is more of a request or a proposal for wlr_render_rect:

1. it could accept 4 colors - one for each of the vertices
2. it would respect the alpha component of the color provided

Rationale:

With the above changes, we could render a lot more "styled" decorations without resorting to cairo and caching textures.
#1 allows for simple gradients
#2 allows for bevels (with some overdraw).
#2 also allows for recoloring textures with gradient overlays.

Why I personally want these changes : I'm trying to recreate the blackbox/fluxbox on wlroots from the tinywl code. Currently, I have to resort to cairo for most of the rendering.

But I think even sway could achieve more styling with the two simple changes.

[emersion]

We kept the renderer to the bare minimum because there'll always be that "one last feature" compositors need. We prefer compositors to directly use OpenGL when they need something more complicated.

[icedman]

This one at least "it would respect the alpha component of the color provided"
..given that the function accepts float[static 4]

[emersion]

This one would be a bug. IIRC it works correctly when we use it in Sway?

[icedman]

I did a quick test with the tinywl code.
Alpha component doesn't affect wl_render_rect. I'm not sure with sway.

for(int i=0;i<10;i++) {
  float box_color[4] = {1.0, 0.0, 1.0, 0.1*i};
    struct wlr_box box = {
      .x = 105*i,
      .y = 0,
      .width = 100,
      .height = 100
    };
  wlr_render_rect(renderer, &box, box_color, output->wlr_output->transform_matrix);
}

https://raw.githubusercontent.com/icedman/tinybox/master/screenshots/tinywl-varying-alpha.png

[ammen99]

I think the source color needs to have premultiplied alpha, right @emersion ?

[emersion]

Oh, good point, forgot about pre-multiplied alpha. @ascent12 Should we handle this in the renderer?

[emersion]

Closing because the original question is answered. Feel free to open a separate bug report for the alpha issue.