3 ms·

> unfortunately ... Is there a better alternative for pixel graphics in the terminal? If yes I'm all ears. The way Sixels encodes pixel data sucks, but current

> unfortunately ... Is there a better alternative for pixel graphics in the terminal? If yes I'm all ears. The way Sixels encodes pixel data sucks, but currently it seems to be the only way to render pixels in the terminal (and that's implemented in more than one terminal application).

kragen 4y ago
you seem to be attempting to define 'terminal' as 'vt100 emulator', which unfortunately condemns you to only unreliable solutions like sixel that are too inefficient to provide smooth graphical interaction and full of compatibility problems. you can plot a graph from a remote machine, sure, but if you want to use your mouse to zoom in on it, you just bought a one-way ticket to jank city but i've used graphical terminals like ncd x terminals since 01994, and they provided smooth graphical interactions even over shared 10-megabit ethernet. current xorg and xwayland do a great job of emulating those terminals, with most of their deficiencies fixed, and ssh has built-in support for transparently passing along the needed credentials xpra works even better, supporting h.264 compression and reattaching to applications you've detached from the big problem with x11 is that trying to write a program to do something simple like display an image or draw a bar graph ensnares you in five pages of bureaucracy to solve that problem i wrote yeso: https://gitlab.com/kragen/bubbleos/blob/master/yeso https://gitlab.com/kragen/bubbleos/blob/master/yeso here's a program to display a png with yeso: #include <yeso.h> int main(int argc, char **argv) { ypic img = yp_read_png(argv[1]); if (!img.p) return 1; ywin w = yw_open(argv[1], img.size, ""); yp_copy(yw_frame(w), img); yw_flip(w); for (;;) yw_wait(w, 0); } it also runs on the linux framebuffer without x-windows here's a color generalization of munching squares in yeso in python: import yeso def munch(t, fb): for y, p in enumerate(fb): for x in range(fb.size.x): p[x] = (t & 1023) - ((x ^ y) & 1023) if __name__ == '__main__': with yeso.Window(u"CPython μunching", (256, 128)) as w: t = 0 while True: with w.frame() as fb: munch(t, fb) t += 1 it uses python context managers so you don't forget to yw_flip() there's also a luajit binding the example programs above are non-interactive, like virtually everything sixel that isn't full-screen; here's a lua program to test mouse interaction: local yeso = require 'yeso' function bounds(a, b) if a < b then return a, b else return b, a end end yeso.Window("mΩuso", {256, 256}):run(function (w) local m, dragStart = {x=128, y=128} while true do for ev in w:events() do if ev.isMouse then m = ev.p if ev:button(1) and dragStart == nil then dragStart = {x=ev.p.x, y=ev.p.y} elseif not ev:button(1) then dragStart = nil end end end w:frame(function (f) f:fill(0x7f7f7f) if dragStart then local minX, maxX = bounds(dragStart.x, m.x) local minY, maxY = bounds(dragStart.y, m.y) f:sub({minX, minY}, {maxX-minX, maxY-minY}):fill(0x336699) end end) w:wait() end end) as for embedding interactive graphics in a text stream, i'm still trying to figure out the bubbleos solution to that. but i'll get there, and the result will be usable over ssh, while sixel probably hasn't gotten there even for low-bandwidth interactive localhost cases and probably never will
- hello_computer 4y ago
  > but i've used graphical terminals like ncd x terminals since 01994, and they provided smooth graphical interactions even over shared 10-megabit ethernet The problem is that with the predominance of toolkits like GTK & Qt in the *nix application space, which pre-rasterize everything for easier cross-platform compatibility, X forwarding is nowhere near as efficient as it once was. Under present circumstances, the h.264 route is probably as good as it gets.
  - kragen 4y ago
    the h.264 route used by xpra is dramatically better than remote x-windows has ever been; x11 forwarding has never been great, for reasons including bufferbloat, compatibility problems, and excessive round trips, even if it's not nearly as bad as sixel
    - hello_computer 4y ago
      i believe MS RDP has also taken that approach https://techcommunity.microsoft.com/t5/security-compliance-and-identity/remote-desktop-protocol-rdp-10-avc-h-264-improvements-in-windows/ba-p/249588 https://techcommunity.microsoft.com/t5/security-compliance-a...
      - kragen 4y ago
        interesting, i thought rdp was a vnc-like protocol with minimal compression, but i don't think i've actually looked at it looks like you're right: > With RDP 8.1 we introduced an AVC/H.264 mixed mode which in addition to using RemoteFX Media Streaming, extended support for AVC/H.264 to images as well, while text is compressed using a proprietary Codec. This mode is used by Windows RT devices running Windows 8.1 and some 3 rd party RDP implementations.
  - hulitu 4y ago
    Real users don't use GTK and QT. Real users use Xt, Xaw(3d) and Motif.
hello_computer 4y ago
https://news.ycombinator.com/item?id=35951733 https://news.ycombinator.com/item?id=35951733
- kragen 4y ago
  base64-encoded graphic files are obviously a much better idea than sixel but graphics really benefits from animation and interactivity

kragen 4y ago

you seem to be attempting to define 'terminal' as 'vt100 emulator', which unfortunately condemns you to only unreliable solutions like sixel that are too inefficient to provide smooth graphical interaction and full of compatibility problems. you can plot a graph from a remote machine, sure, but if you want to use your mouse to zoom in on it, you just bought a one-way ticket to jank city but i've used graphical terminals like ncd x terminals since 01994, and they provided smooth graphical interactions even over shared 10-megabit ethernet. current xorg and xwayland do a great job of emulating those terminals, with most of their deficiencies fixed, and ssh has built-in support for transparently passing along the needed credentials xpra works even better, supporting h.264 compression and reattaching to applications you've detached from the big problem with x11 is that trying to write a program to do something simple like display an image or draw a bar graph ensnares you in five pages of bureaucracy to solve that problem i wrote yeso: https://gitlab.com/kragen/bubbleos/blob/master/yeso https://gitlab.com/kragen/bubbleos/blob/master/yeso here's a program to display a png with yeso: #include <yeso.h> int main(int argc, char **argv) { ypic img = yp_read_png(argv[1]); if (!img.p) return 1; ywin w = yw_open(argv[1], img.size, ""); yp_copy(yw_frame(w), img); yw_flip(w); for (;;) yw_wait(w, 0); } it also runs on the linux framebuffer without x-windows here's a color generalization of munching squares in yeso in python: import yeso def munch(t, fb): for y, p in enumerate(fb): for x in range(fb.size.x): p[x] = (t & 1023) - ((x ^ y) & 1023) if __name__ == '__main__': with yeso.Window(u"CPython μunching", (256, 128)) as w: t = 0 while True: with w.frame() as fb: munch(t, fb) t += 1 it uses python context managers so you don't forget to yw_flip() there's also a luajit binding the example programs above are non-interactive, like virtually everything sixel that isn't full-screen; here's a lua program to test mouse interaction: local yeso = require 'yeso' function bounds(a, b) if a < b then return a, b else return b, a end end yeso.Window("mΩuso", {256, 256}):run(function (w) local m, dragStart = {x=128, y=128} while true do for ev in w:events() do if ev.isMouse then m = ev.p if ev:button(1) and dragStart == nil then dragStart = {x=ev.p.x, y=ev.p.y} elseif not ev:button(1) then dragStart = nil end end end w:frame(function (f) f:fill(0x7f7f7f) if dragStart then local minX, maxX = bounds(dragStart.x, m.x) local minY, maxY = bounds(dragStart.y, m.y) f:sub({minX, minY}, {maxX-minX, maxY-minY}):fill(0x336699) end end) w:wait() end end) as for embedding interactive graphics in a text stream, i'm still trying to figure out the bubbleos solution to that. but i'll get there, and the result will be usable over ssh, while sixel probably hasn't gotten there even for low-bandwidth interactive localhost cases and probably never will

hello_computer 4y ago
> but i've used graphical terminals like ncd x terminals since 01994, and they provided smooth graphical interactions even over shared 10-megabit ethernet The problem is that with the predominance of toolkits like GTK & Qt in the *nix application space, which pre-rasterize everything for easier cross-platform compatibility, X forwarding is nowhere near as efficient as it once was. Under present circumstances, the h.264 route is probably as good as it gets.
- kragen 4y ago
  the h.264 route used by xpra is dramatically better than remote x-windows has ever been; x11 forwarding has never been great, for reasons including bufferbloat, compatibility problems, and excessive round trips, even if it's not nearly as bad as sixel
  - hello_computer 4y ago
    i believe MS RDP has also taken that approach https://techcommunity.microsoft.com/t5/security-compliance-and-identity/remote-desktop-protocol-rdp-10-avc-h-264-improvements-in-windows/ba-p/249588 https://techcommunity.microsoft.com/t5/security-compliance-a...
    - kragen 4y ago
      interesting, i thought rdp was a vnc-like protocol with minimal compression, but i don't think i've actually looked at it looks like you're right: > With RDP 8.1 we introduced an AVC/H.264 mixed mode which in addition to using RemoteFX Media Streaming, extended support for AVC/H.264 to images as well, while text is compressed using a proprietary Codec. This mode is used by Windows RT devices running Windows 8.1 and some 3 rd party RDP implementations.
- hulitu 4y ago
  Real users don't use GTK and QT. Real users use Xt, Xaw(3d) and Motif.

hello_computer 4y ago

https://news.ycombinator.com/item?id=35951733 https://news.ycombinator.com/item?id=35951733

kragen 4y ago
base64-encoded graphic files are obviously a much better idea than sixel but graphics really benefits from animation and interactivity