Commit Graph

7 Commits

Author SHA1 Message Date
dundargoc
1813661a61 refactor(IWYU): fix headers
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
2024-01-11 21:37:23 +01:00
dundargoc
af93a74a0f refactor: run IWYU on entire repo
Reference: https://github.com/neovim/neovim/issues/6371.
2023-12-21 17:38:42 +01:00
dundargoc
79b6ff28ad refactor: fix headers with IWYU 2023-11-28 22:23:56 +01:00
dundargoc
353a4be7e8 build: remove PVS
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
2023-11-12 21:26:39 +01:00
dundargoc
2dc9ceb99c docs: small fixes (#25585)
Co-authored-by: tmummert <doczook@gmx.de>
Co-authored-by: parikshit adhikari <parikshitadhikari@gmail.com>
2023-10-29 16:02:32 +08:00
zeertzjq
cf8b2c0e74 build(iwyu): add a few more _defs.h mappings (#25435) 2023-09-30 12:05:28 +08:00
bfredl
8da986ea87 refactor(grid): change schar_T representation to be more compact
Previously, a screen cell would occupy 28+4=32 bytes per cell
as we always made space for up to MAX_MCO+1 codepoints in a cell.

As an example, even a pretty modest 50*80 screen would consume

50*80*2*32 = 256000, i e a quarter megabyte

With the factor of two due to the TUI side buffer, and even more when
using msg_grid and/or ext_multigrid.

This instead stores a 4-byte union of either:
- a valid UTF-8 sequence up to 4 bytes
- an escape char which is invalid UTF-8 (0xFF) plus a 24-bit index to a
  glyph cache

This avoids allocating space for huge composed glyphs _upfront_, while
still keeping rendering such glyphs reasonably fast (1 hash table lookup
+ one plain index lookup). If the same large glyphs are using repeatedly
on the screen, this is still a net reduction of memory/cache
consumption. The only case which really gets worse is if you blast
the screen full with crazy emojis and zalgo text and even this case
only leads to 4 extra bytes per char.

When only <= 4-byte glyphs are used, plus the 4-byte attribute code,
i e 8 bytes in total there is a factor of four reduction of memory use.
Memory which will be quite hot in cache as the screen buffer is scanned
over in win_line() buffer text drawing

A slight complication is that the representation depends on host byte
order. I've tested this manually by compling and running this
in qemu-s390x and it works fine. We might add a qemu based solution
to CI at some point.
2023-09-19 11:25:31 +02:00