diff options
author | Avi Halachmi (:avih) <avihpit@yahoo.com> | 2020-11-26 23:25:07 +0200 |
---|---|---|
committer | Avi Halachmi (:avih) <avihpit@yahoo.com> | 2020-11-27 00:25:32 +0200 |
commit | 59c32a04b04dc42dd17665834a9f2ce35a48eeaf (patch) | |
tree | 20931fc7394217b4a9a937c8e334a4625fe64df9 /TOOLS | |
parent | 1bb2665e3d099a792cf9c4e5b119a6b4352d9b2f (diff) | |
download | mpv-59c32a04b04dc42dd17665834a9f2ce35a48eeaf.tar.bz2 mpv-59c32a04b04dc42dd17665834a9f2ce35a48eeaf.tar.xz |
vo_sixel: fix the image corruption with mlterm
The issue was that we only uploaded the palette to the terminal when it
changed (once on init with fixed palette, every frame with dynamic
palette with trheshold=-1, only on scene change with threshold >= 0).
Now we upload it on every frame, and it seems to fix the mlterm image
corruption both with fixed palette and also with dynamic palette with
threshold (i.e. at frames which did not upload a palette).
It's not entirely clear why it's required with mlterm.
It would seem that the palette which libsixel uses with fixed palette
matches the built in default palette in xterm, but not in mlterm.
With dynamic palette we can guess that mlterm resets the palette after a
sixel image, but that's not confirmed.
Uploading the palette on every frame doesn't seem to slow down xterm
when using fixed palette - not clear yet why uploading a different
palette (when using fixedpalette=no) slows it down while same palette
on every frame doesn't.
In mlterm there's no slowdown either way - and now also no corruption.
Diffstat (limited to 'TOOLS')
0 files changed, 0 insertions, 0 deletions