blob: c6a4c1238fb96b026b8745c6723ce1a3735eef7f [file] [view]
{% set rfcid = "RFC-0094" %}
{% include "docs/contribute/governance/rfcs/_common/_rfc_header.md" %}
# {{ rfc.name }} - {{ rfc.title }}
<!-- DO NOT EDIT ANYTHING ELSE ABOVE THIS LINE. -->
## 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](/zircon/system/ulib/gfx)) to a Rust based
[Carnelian](/src/lib/ui/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:
1. Virtcon.
2. 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](/zircon/system/ulib/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](https://rive.app) 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](/src/recovery/system/)
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-controller API](/sdk/fidl/fuchsia.hardware.display/display-controller.fidl) 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](/src/bringup/bin/virtcon/README.md).