LRUMap implements the parts of an ordered map that we need to
efficiently implement DynamicCharAtlas. It's more code, but there's a
few advantages of this approach:
- Map isn't available on some older browsers, so this removes the need
for a polyfill.
- Moving an item to the end of the map's iteration order now only
requires unlinking and linking a linked-list node, whereas before we
had to delete and re-insert our value.
- Peeking at the oldest entry in the map no longer requires allocating
and destroying an iterator.
- We can preallocate the linked-list nodes we want to improve cache
locality. Similarly, we can recycle linked-list nodes to reduce
allocations and the GC pauses those allocations may cause.
- LRUMap seems to give slightly better results in Chrome's profiler than
Map did. We now spend about 5% of our time on map operations instead
of about 10%.
- In my (limited) testing, it doesn't look like LRUMap is slowing down
over time. Map appeared to get slightly slower the longer I ran the
terminal for, either due to memory fragmentation or some sort of leak.
I still need to write some tests for LRUMap, but I've been using this
implementation for the last hour without problems.
When we remove the background from a glyph, we can keep track of if we
made all the pixels fully transparent. If we did, we can just skip
future calls to _drawFromCache, since it would be a noop anyways.
This adds a very minimal implementation of DynamicCharAtlas using a LRU
cache.
I've got some optimizations that I'll add on top of this, but this
proves the concept.
This adds the logic needed to switch between multiple char atlas
implementations, and an example second implementation to test it out
with.
This also offers an escape hatch if something goes wrong with the char
atlas implementation(s).
The API defined by BaseCharAtlas will let us support multiple char atlas
implementations at once.
I tested this by running the demo with Chrome's profiler, which shows
that calls are going to StaticCharAtlas/drawImage instead of
_drawUncachedChar. Applications using 256 colors also still work fine,
via _drawUncachedChar.
I have added blob handler for the attach Addon.
This allows to handle Docker with ws (works on Docker API v1.35)
I have also added a callback to handle asynchronous FileReader.
This mostly worked before, but clearColor made the assumption that the
colors were always in #RRBBGG format. See the discussion here:
https://github.com/xtermjs/xterm.js/pull/1327#issuecomment-374812842
This changes the internal representation of a color so that we hold onto
into an object containing the original css string along with an RGBA
value encoded as a 32-bit uint. clearColor can then use that RGBA
representation.
Additionally, this deduplicates some code between ColorManager and
Terminal. Terminal was generating the 256 ansi colors the same way
ColorManager was, so this just makes Terminal use the same constant.
Selected inline-styles were externalized to xterm.css.
The `Terminal._charSizeStyleElement` is removed since it
was not used anymore.
Fixes: https://github.com/xtermjs/xterm.js/issues/1335
ICharAtlasRequest and ICharAtlasConfig need almost exactly the same set
of information, so it's simpler if we just merge the two types.
As an added bonus, this also adds devicePixelRatio to the config, which
helps guarantee that we won't ever accidentally end up with an atlas
using a different pixel ratio than we need.
Benjamin Woodruff
Daniel Imms
jpoth
Daniel Imms
Felipe Gasper
Paris Kasidiaris
Alexandre Petit-Pas
Lucian Buzzo
Marek Libra