r-alacritty.git/alacritty/res, branch experimental My custom-patched version of alacritty. Add Sixel support 2021-08-17T13:44:40+00:00 Ayose ayosec@gmail.com 2021-03-10T20:21:36+00:00 0fd3793a963015e8f91021e35dbb2169d15c3211 Fixes #910 
Fixes #910
Add option to apply opacity to all background colors 2021-08-16T11:49:14+00:00 Kirill Chibisov contact@kchibisov.com 2021-08-16T11:49:14+00:00 c24d7dfd0d2d8849f0398d7cb1a65d6562ee7a0d In some cases it could be desired to apply 'background_opacity' to all background colors instead of just 'colors.primary.background', thus adding an 'colors.opaque_background_colors' option to control that. Fixes #741. 
In some cases it could be desired to apply 'background_opacity'
to all background colors instead of just 'colors.primary.background',
thus adding an 'colors.opaque_background_colors' option to control that.

Fixes #741.
 Render underline and strikeout rects in batches 2020-12-10T05:42:03+00:00 Ivan Avdeev marflon@gmail.com 2020-12-10T05:42:03+00:00 5ececc310508c1cdc590d4b6dea9ec2e99475c38 Currently Alacritty requires a separate `draw` call to OpenGL whenever a new rectangle is rendered to the screen. With many rectangles visible, this has a significant impact on rendering performance. Instead of using separate draw calls, the new `RectRenderer` will build a batch of rectangles for rendering. This makes sure that multiple rectangles can be grouped together for single draw calls allowing a reduced impact on rendering time. Since this change is OpenGL 2 friendly, it should not make it more complicated to transition away from the 3.3+ requirements like an alternative instancing based implementation might have. 
Currently Alacritty requires a separate `draw` call to OpenGL whenever a
new rectangle is rendered to the screen. With many rectangles visible,
this has a significant impact on rendering performance.

Instead of using separate draw calls, the new `RectRenderer` will build
a batch of rectangles for rendering. This makes sure that multiple
rectangles can be grouped together for single draw calls allowing a
reduced impact on rendering time.

Since this change is OpenGL 2 friendly, it should not make it more
complicated to transition away from the 3.3+ requirements like an
alternative instancing based implementation might have.
Fix wide characters being cut off 2020-11-17T14:49:05+00:00 Kirill Chibisov contact@kchibisov.com 2020-11-17T14:49:05+00:00 9724418d350df881afe8453bde6eb88643e7211e Fixes #791. 
Fixes #791.
 Remove copyright notice from files 2020-08-10T13:07:19+00:00 Kirill Chibisov contact@kchibisov.com 2020-08-10T13:07:19+00:00 ef7cb258b2c972c24de78e0d77940db13ecd8ce3 This commit is a follow-up to 7aafbb757d485c5ff065324464dde8b5322cdd921 which was an effort to remove copyright notice from files. 
This commit is a follow-up to 7aafbb757d485c5ff065324464dde8b5322cdd921
which was an effort to remove copyright notice from files.
 Reduce InstanceData footprint 2020-08-05T00:24:51+00:00 Joe Wilm jwilm@users.noreply.github.com 2020-08-05T00:24:51+00:00 99c34c7ce92fe02c733b5fd19dd054783038f037 The InstanceData type in the rendering subsystem was previously 17 f32s plus one u8 which occupied a total of 72 bytes per instance. This meant that for every character or background cell drawn, 72 bytes were sent to the GPU. In the case of a 400x100 cell grid, a total of 2.9MB would be sent. This patch reduces InstanceData's size to 36 bytes, a 50% improvement! Using the above example for comparison, a worst case of 1.44MB would be transferred. The motivation for this patch comes from macOS. Once the terminal grid would reach a certain size, performance experienced a sharp and dramatic drop (render times would go from ~3ms to ~16ms). I don't want to speculate too much on the underlying issue, but suffice it to say that this patch alleviates the problem in my testing. While the performance impact was most significant on macOS, with rendering times cut by more than 50% in some cases, this also results in a measurable performance difference on other systems with high density grids. Co-authored-by: Christian Duerr <contact@christianduerr.com> 
The InstanceData type in the rendering subsystem was previously 17 f32s
plus one u8 which occupied a total of 72 bytes per instance. This meant
that for every character or background cell drawn, 72 bytes were sent to
the GPU. In the case of a 400x100 cell grid, a total of 2.9MB would be
sent.

This patch reduces InstanceData's size to 36 bytes, a 50% improvement!
Using the above example for comparison, a worst case of 1.44MB would be
transferred.

The motivation for this patch comes from macOS. Once the terminal grid
would reach a certain size, performance experienced a sharp and dramatic
drop (render times would go from ~3ms to ~16ms). I don't want to
speculate too much on the underlying issue, but suffice it to say that
this patch alleviates the problem in my testing.

While the performance impact was most significant on macOS, with
rendering times cut by more than 50% in some cases, this also results in
a measurable performance difference on other systems with high density
grids.

Co-authored-by: Christian Duerr <contact@christianduerr.com>
 Fix crates.io publishing restrictions 2020-08-01T01:11:24+00:00 Christian Duerr contact@christianduerr.com 2020-08-01T01:11:24+00:00 9167461eb35687872a7670b2e7105a56244f7a48 This works around the problem that crates pushed to crates.io cannot reference files outside of their crate directory. 
This works around the problem that crates pushed to crates.io cannot
reference files outside of their crate directory.