bevyengine / bevyengine/bevy

Support dynamic text rasterization size

Open
#24,120 0 comments 0 reactions 0 assignees View on GitHub
A-Rendering A-Text C-Feature D-Complex S-Needs-Design
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 22h
Merged PRs (30d)
161

Description

## What problem does this solve or what need does it fill?

Bevy currently couples text rasterization size directly to font size, which is also used as a logical unit for UI layout. This makes it difficult to render high resolution text (e.g. for zoomable interfaces like node graphs or other editors) without also affecting layout size.

Existing workarounds such as increasing font size and scaling down via `UiTransform`, or using `UiScale` are cumbersome, fragile, and can introduce layout inconsistencies. They also lack flexibility, because layout is calculated before `UiTransform` scale is applied.

## What solution would you like?

A solution that allows dynamic control, ideally hierarchical, over text rasterization resolution independently of layout size would be ideal and was implemented in #24061, however this added too much extra complexity for a relatively niche feature.

## What alternative(s) have you considered?

An alternative solution, which scales the logical to physical pixel conversion was implemented by @ickshonpe as https://github.com/ickshonpe/bevy_ui_local_scale. This solution is hierarchical and has less downsides than the other current workarounds, however, you still need to inversely scale via `UiTransform` for the text to be the desired size on screen, making zoom implementations that want to dynamically change the text rasterization size based on zoom level tricky. Dynamically changing text rasterization size based on zoom level is required for text to maintain good legibility at all zoom level. Small rasterization size reads better when zoomed out, while high rasterization size reads better when zoomed in.

Another possible solution is to support vector based text rendering, which is more expensive (and might look a little worse?), but would be perfect for this use case, but would introduce a completely separate text rendering path - high complexity.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.