You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Basically we should not strip empty sixel bands at all, but account them in size calculation. This kinda contradict the idea to get the smallest area of pixels touched by sixels in a sense of image dimensions, thus needs some fundamental rework of how the decoder propagates the result.
Possible ideas:
introduce a more low level interface directly working on band level and let the consumer decide whether to turn them into a big image blob or keep them as stripes
keep main image like logic intact, but announce additionally sixel cursor moves from GLFs
draw more directly on canvas, e.g. provide an interface for hooking a canvas (slices) to directly draw on (would also solve the composition/overdraw issue currently lacking in the xterm.js addon)
The text was updated successfully, but these errors were encountered:
The size calculation is off in several ways (see jerch/xterm-addon-image#37 for details).
Basically we should not strip empty sixel bands at all, but account them in size calculation. This kinda contradict the idea to get the smallest area of pixels touched by sixels in a sense of image dimensions, thus needs some fundamental rework of how the decoder propagates the result.
Possible ideas:
The text was updated successfully, but these errors were encountered: