Support Multi-Size SVG Variants in Icon Generation for Crisp Rendering

[jonathansampson]

Description:

Currently, the Leo pipeline converts a single default SVG (e.g. browser-back.svg) into a .icon file. This .icon file contains only one representation, which can lead to blurry icons on non-HDI displays because Chromium’s system expects multiple, size-optimized representations (using CANVAS_DIMENSIONS blocks).

Proposed Solution:

• Adopt a Naming Convention:

  • The base file (e.g. browser-back.svg) will serve as the default.
  • Size-specific variants will be provided with dimensional suffixes (e.g. browser-back_32.svg, browser-back_16.svg).

• Modify the Icon Generation Script:

  • Update gen-skia-icons.ts so that:
    • It excludes files with dimensional suffixes when gathering defaults.
    • When processing a default SVG, it searches for variant SVGs (based on the naming convention) and includes them in the generated .icon file.
    • Each variant is output as a separate representation with its own CANVAS_DIMENSIONS block.

This approach leverages the existing build pipeline and minimizes changes while providing the necessary multiple representations for crisp rendering across different display densities.

Additional Context:

• This enhancement will help address reports of blurry vector icons on non-HDI displays.
• It aligns Brave's icon generation with Chromium’s expectations, ensuring a better visual experience without overhauling the entire process.

[aguscruiz]

Just to mention, an alternative approach to this would be to convert all our icons from fills to outlines, so they can be scaled down better and keep the stroke width they're supposed to have, and ideally, not present antialias artifacts.

But it's a long approach, means redrawing every icon and making sure they fit the pixel grid perfectly.

[fallaciousreasoning]

It also might make resizing look a bit odd because we have no way to tie the stroke thickness to the size of the icon

[jonathansampson]

It also might make resizing look a bit odd because we have no way to tie the stroke thickness to the size of the icon

Or do we? :) ui/gfx/paint_vector_icon.cc defines the PaintPath method. It looks as though we have both the stroke-control and the canvas size within context, such that we could base one on the other if we so desired. Might be worth experimenting?