vello_hybrid: support blurred rounded rects fast path

[waywardmonkeys]

This wires Hybrid through the existing shared vello_common blurred rounded rect encoding, adds GPU/WebGL encoded paint upload support, and teaches the sparse strip shader to evaluate the analytic blurred rounded rect paint. Root-level unclipped cases use the existing direct rectangle fast path; other supported cases fall back through the normal strip/coarse path.

Also adds a small Hybrid winit demo scene, adapted from the Classic test scene, so the feature can be inspected interactively.

[waywardmonkeys]

This was done with the assistance of Codex (5.5, high). I've reviewed it and think it is right, but I don't know all of the hybrid internals to be sure I didn't miss something.

[DJMcNab]

Does this address #1373?

[LaurenzV]

LGTM overall, from some testing on my tablet I wasn't able to determine any slowdown from adding this additional shader code.

[LaurenzV]

I can probably just do it myself depending on which PR gets merged first, but just as a note the way we process paint types is likely to change here: https://github.com/linebender/vello/pull/1619/changes

[LaurenzV]

Can you maybe add a note that 0.5 and 0.0 correspond to v0 and v1 in the CPU code? And in general, a small comment that this shader is modelled after the vello_cpu variant (instead of vello itself)

[waywardmonkeys]

Done.

[LaurenzV]

Now we are doing the computation twice, once here and then again in try_fast_rect_with_paint. Could we not change it so that

1. fast_rect_bounds just returns a normal Optionkurbo::Rect (since the coordinates are f64 anyway) and then
2. Turn try_fast_rect_with_paint into a method that takes the calculated bounds directly and just pushes it to the fast strips buffer (and rename into something like push_fast_rect)?

[waywardmonkeys]

Improved now, I think.

[LaurenzV]

I wonder whether all of this can be deduplicated somehow, but maybe better for a follow-up.

[grebmeg]

I checked on a low-tier device, a Samsung Galaxy A05s, to make sure the PR doesn’t degrade performance, and it looks like it doesn’t. I ran fairly intensive tests with 10 warm-up runs and 100 iterations for each benchmark.

From the results, there doesn’t seem to be any noticeable degradation, although benchmarking GPU performance properly is always tricky... In interactive mode, it feels fine as well.

Ideally, we’d introduce feature gating for such features, but we currently don’t have the infrastructure for that. The long-term plan is to move to more specialized shaders, but until then, I still think it’s better to have the feature gating in place since it doesn’t take much effort to implement. Otherwise, users might not even use some of these features, but still end up paying the performance cost for them.

[waywardmonkeys]

Ideally, we’d introduce feature gating for such features, but we currently don’t have the infrastructure for that. The long-term plan is to move to more specialized shaders, but until then, I still think it’s better to have the feature gating in place since it doesn’t take much effort to implement. Otherwise, users might not even use some of these features, but still end up paying the performance cost for them.

You'll have to sort out the CI cost / impact for this due to how CI checks features. That makes additional features more painful (and it is already bad).