glutin::Window is not threadsafe; putting it into an Arc is
misleading (although the glutin::Window type claims to be Send + Sync).
The reference was just needed on the main thread anyway, so it's better
to just pass a ref around directly.
There's now a ColorList type that provides strongly typed indexing for
not only usize but NamedColor as well. Previously, the `NamedColor` was
casted to a `usize` when indexing the colors. Additionally, only one
copy of the ColorList needs to exist;it's borrowed from the `Config`
when rendering, and the renderer doesn't need a copy.
ANSI escape sequences like `\x1b[48;5;10m` were not supported until now.
Specifically, the second attribute, 5, says that the following attribute
is a color index.
The ref tests were updated since `enum Color` variants changed.
This probably should have been renamed in the original refactor, but oh
well. `render_cells()` takes a generic parameter `I` which is any
`Iterator<Item=IndexedCell>` and is thus no longer coupled to the grid
type. Renaming it reflects that.
The terminal now has a `renderable_cells()` function that returns a
`RenderableCellIter` iterator. This allows reuse of the cell selection
code by multiple renderers, makes it testable, and makes it
independently optimizable.
The render API now takes an `Iterator<Item=IndexedCell>` to support both
the new renderable cells iterator and the `render_string()` method which
generates its own iterator.
The `vim_large_window_scoll` ref test was added here because it provides
a nice large and busy grid to benchmark the cell selection with.
Ref tests use a recording of the terminal protocol and a serialization
of the grid state to check that the parsing and action handling systems
produce the correct result. Ref tests may be recorded by running
alacritty with `--ref-test` and closing the terminal by using the window
"X" button. At that point, the recording is fully written to disk, and a
serialization of important state is recorded. Those files should be
moved to an appropriate folder in the `tests/ref/` tree, and the
`ref_test!` macro invocation should be updated accordingly.
A couple of changes were necessary to make this work:
* Ref tests shouldn't create a pty; the pty was refactored out of the
`Term` type.
* Repeatable lines/cols were needed; on startup, the terminal is resized
* by default to 80x24 though that may be changed by passing
`--dimensions w h`.
* Calculating window size based on desired rows/columns and font metrics
required making load_font callable multiple times.
* Refactor types into library crate so they may be imported in an
integration test.
* A whole bunch of types needed symmetric serialization and
deserialization. Mostly this was just adding derives, but the custom
deserialization of Rgb had to change to a deserialize_with function.
This initially adds one ref test as a sanity check, and more will be
added in subsequent commits. This initial ref tests just starts the
terminal and runs `ll`.
Bindings were previously hardcoded within input.rs; adding, removing, or
changing a binding required a recompile! Now, bindings may be declared
in alacritty.yml. Even better, bindings are live-reloaded when
alacritty.yml is changed!
One unexpected benefit of this change was that all of the special casing
in input.rs has disappeared.
Conversely, config.rs has gained complexity for all of the
deserialization logic.
Resolves#3.
This still has a problem where intermediate sizes are not drawn.
Apparently cocoa blocks the event loop during resize. This needs to be
fixed in Glutin.
Resolves#16.
There's an issue where drawing the cell backgrounds will overwrite part
of a neighboring glyph. The real solution here is to figure out glyph
metrics properly, but simply limiting to 2 draw calls per frame (first
background, then all the glyphs) makes the problem "go away".
Indexing colors on the vertex shader added complexity and after
profiling suggests perf is basically the same. This commit will still be
here in case it makes sense to try this again at some point.
This feature was previously shoved into the renderer due to initial
proof of concept. Now, providing config updates to other systems is
possible. This will be especially important for key bindings!
Which means it can be disabled in release builds. No more working on a
renderer feature and actually breaking the Alacritty your editor is
running inside.
Move more work to GPU from CPU. Some very non-scientific profiling
suggests this is implementation is more performant, but more work should
be done there.
The architecture here is really poor. Need to move file watching into a
dedicated location and probably have an spmc broadcast queue. other
modules besides rendering will care about config reloading in the
future.
Joe Wilm