GLES2 has GL_EXT_blend_func_extended extension that enables
dual-source blending, so essentially we can reuse fragment shader
from GLSL3 renderer and do 1 rendering pass instead of 3 for the
text.
Co-authored-by: Kirill Chibisov <contact@kchibisov.com>
Co-authored-by: Christian Duerr <contact@christianduerr.com>
Currently Alacritty only works on hardware which supports OpenGL 3.3 or
more, which can become problematic with older devices. This patch adds a
new GLES2 renderer, since it is much more widely supported, especially
on weaker hardware like phones or a Raspberry Pi.
While the GLES2 renderer is slower than the OpenGL 3.3+ version, it is
still significantly faster than software rendering. However because of
this performance difference it is only used when necessary and there
should be no difference for machines supporting OpenGL 3.3+.
The two renderers are largely independent and separated in the
`renderer/text/glsl3` and `renderer/text/gles2` modules. Separate
shaders are also required for text rendering. The rectangle rendering
for underlines and the visual bell works identically for both versions,
but does have some version-specific shader code.
Fixes#128.
Co-authored-by: Christian Duerr <contact@christianduerr.com>
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.
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.
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>