New triangle collapse arrow for large collapsible header

[abey79]

What

This PR implements the proper Figma-based collapsing arrow (with "linearised" rounded corners) and uses it for the large collapsible headers in the selection panel. This PR also fixes the vertical optical alignment of the text within these headers.

Partially addresses #2738

Zoom 150%:

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested demo.rerun.io (if applicable)

• PR Build Summary
• Docs preview
• Examples preview

[martenbjork]

Looks good visually!

As we discussed on the huddle, there will be many icons, so it's good if adding icons isn't messy code wise or takes a lot of time. Some approaches we talked about:

• Linearizing the paths like this PR does
• Extracting path data from SVG attributes
• Apple approach: Adding multiple images like [email protected], [email protected] etc and choosing them based on ui zoom level.

Anyways, I'll leave this to you!

[abey79]

Yes, that's on my long list of topics to run by @emilk.

That being said and regardless of where we're going with icons in general, the collapsing arrow may deserve special treatment because of the rotation animation. I think this is the lens with which this PR should be evaluated.

[abey79]

One clear shortcoming of this PR is that it doesn't document how I came up with the coordinates. I don't think the process is clean enough to be included though. For reference, here is the command I used:

vpype read -q 0.15 arrow.svg scale -o 0 0 %100/12% %100/12% pagesize 100x100 scale -o 50 50 %75/50% jinja -p rustvec.txt

where:

• arrow.svg is a SVG I manually exported from Figma
• jinja -p rustvec.txt is a command from a new, yet unpublished vpype plugin of mine 😓

Edit: BTW the ridiculous chaining of various scaling commands is the result of my process back then btw. Should definitely be cleaned up as well.

[emilk]

We should create a proper issue about how to do icons. Some quick, random thoughts:

There are at least three things to consider:

• Ease of changing out icons (e.g just drop a .png or .svg in folder)
• Low code bloat (don't increase .wasm size too much)
• Visual quality (icons shouldn't be blurry, no matter what dpi scaling the user has)

There are two major ways to go.

Imagers (e.g. .png)

• very easy to create and use
• but one imager will never be optimal for all resolution scalings.
  • we could export one high-res .png and dynamically rescale it to fit the users resolution. Pretty easy to implement, and low code bloat.

Vector graphics

Using epaint vector rendering (like this PR) works great (proper anti-aliasing for all resolutions), but only for convex polygons.

Dor concave polygons we either need to implement something new in epaint, or use some 3rd party rendering tool (more code bloat)

• egui_extras uses a lot of dependencies for this, see https://docs.rs/egui_extras/latest/egui_extras/image/struct.RetainedImage.html#method.from_svg_bytes

.svg is a horribly complex format. tinyvg is an interesting new alternative, but still requires us to ship code for parsing and rasterizing, increasing .wasm size.

Conclusions?

I'm leaning towards using a single high-res .png for each icon, then resize it using some high-quality algo (e.g. Lanczos filtering) to create a crisp icon for the current resolution scaling.

Easy to use, easy to implement, high-quality, low code bloat.

[abey79]

Icon discussion moved here: #2960

[emilk]

Looks good!

[emilk]

Perhaps link to #2960 here so we remember to update this code once that issue is resolved