| RFC-0094: Carnelian Virtcon | |
|---|---|
| Status | Accepted |
| Areas |
|
| Description | Convert Virtcon from a C++ program to a Rust based Carnelian application. |
| Issues | |
| Gerrit change | |
| Authors | |
| Reviewers | |
| Date submitted (year-month-day) | 2021-04-21 |
| Date reviewed (year-month-day) | 2021-05-04 |
Summary
This document proposes a plan for converting the Virtual Console (Virtcon) from a C++ program with a custom low-level graphics library (See gfx) to a Rust based Carnelian application. The Terminal application code used for Workstation and Terminal products will be unified with Virtcon in the process, and Virtcon will gain the ability to use advanced vector graphics and scalable text with high quality anti-aliasing.
Motivation
Reducing complexity and code
Fuchsia is currently maintaining two terminal implementations:
- Virtcon.
- Terminal application for the Workstation product.
Virtcon implements its own limited software rendering library, while the Terminal application is powered by Carnelian's advanced vector graphics rendering backend. There is a large amount of code duplication between these implementations and reducing that would be a net positive for the platform. The legacy graphics library (gfx) used by Virtcon today can be deleted and we can reduce the number of ways that we interact with the display controller API when this transition has completed.
New features
Carnelian-based Virtcon will maintain support for flicker-free single buffer mode rendering while introducing support for tear-free double buffered output on devices with sufficient display driver support. This improves the visual appearance and results in better integration with some hardware (E.g. FEMU) where single buffer mode is not well supported.
Scalable text
Carnelian's support for efficient rendering of scalable vector graphics (including text) makes it trivial to adjust the size of console text to match the density of the display.
Splash screen
The transition to Carnelian will modernize Virtcon and enable splash screen functionality that existing and future products will benefit from. For example, an animation can be presented during boot and the debuglog can be hidden unless the user press a special key or an error occurs. Carnelian's support for rive animations provide a seamless way to design and integrate UI assets, while maintaining low resource usage and efficient rendering.
Design
Virtcon is used for bringup and it is critical that it continues to be functional for this use-case. Any design changes that prevent that will not be accepted.
Carnelian allows applications to run without Scenic or Root Presenter and has an efficient software renderer for situations where Vulkan is not available. This is already in use by the recovery UI and the additional steps needed to allow a Carnelian-based application to replace Virtcon has already been completed. Carnelian applications running without Scenic communicate directly with display and input drivers in a similar way to legacy Virtcon.
Carnelian-based Virtcon will be designed to maximize code reuse with the Terminal application.
Fuchsia developers should not notice a significant difference from this transition. Hardware requirements and FIDL APIs used to interface with Virtcon are not changing.
Implementation
Carnelian-based Virtcon will be similar to the recovery UI application but connect to the display controller as a Virtcon client instead of as a Primary client (See the display-coordinator API for details about the difference).
Maximum code reuse with the Terminal application will be accomplished by implementing all shared logic as rust libraries that both components can use. In some cases, this means extracting Terminal code into libraries.
A Carnelian-based text grid will be developed to power both the Terminal application and Virtcon. This text grid will take advantage of Carnelian's support for partial screen updates to provide performance that match legacy Virtcon.
Performance
Performance and resource usage is a critical aspect of this project. It is critical that performance and memory usage does not regress significantly as part of this transition. Double buffering is expected to increase memory usage but that feature should be optional.
There should be no significant difference in:
- CPU usage.
- Memory usage.
- Build time.
The binary size of Virtcon is expected to grow but should be kept less than 1MiB.
Testing
Test coverage for Virtcon should be the same or improved. All new Rust code is expected to have unit tests and existing integration tests should be converted to the new version of Virtcon.
Documentation
At this stage, we plan to document Carnelian-based Virtcon through this RFC, and this README.md.