4 ms·

That sounds strange - mind you I'm not familiar with Plan 9, but was the graphics wire protocol text-based? If yes, why wasn't the separation handled by newline

That sounds strange - mind you I'm not familiar with Plan 9, but was the graphics wire protocol text-based? If yes, why wasn't the separation handled by newlines? I'm sure you can encode command separators in binary without the need to rely on write flushes.

pjmlp 4y ago
Have some fun reading about Carmack's point of view on Plan 9 graphics. https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4
- hulitu 4y ago
  > Have some fun reading about Carmack's point of view on Plan 9 graphics. > https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4 > "Computers should feel instant whenever possible. This involves the event path, whatever processing is done, the speed of drawing, and the way the drawing is displayed." This was 27 years ago and still no progress on this field.
  - zozbot234 4y ago
    Wayland and X compositors provide for tear-free video updates, which is what Carmack is talking about in those posts. Further progress will come from lowering the added latency, but that's a very different problem.
    - hedora 4y ago
      He goes on to complain about precursors to compositing. By the late 1990's Linux supported tear free with lower latency than compositors currently support. Anyway, computers have been getting worse at output latency since the mid 1980's. Compositing is just yet another ratcheted performance and usability regression.
      - zozbot234 4y ago
        Late-1990s systems supported practically tear-free updates for most practical uses, but AIUI there was not enough memory bandwidth for whole-screen updates to be tear-free, especially at higher resolutions and color depths. This is what Carmack is complaining about here. Even then, there are better and worse ways of coping with limited video memory bandwidth, and what's "best" depends on the given application.
        hedora 4y ago
        According to Carmack (in 1995), tear free compatible PCI bandwidth was just starting to hit the market. This matches my memory of configuring tear free before y2k. I know for sure that I had tear free working at 1600x1200x24 (or 16?) by 2001.
      - mananaysiempre 4y ago
        FWIW, the Plan 9 window system is in fact a (very barebones) compositor in modern terms, in that it (unlike classic X and like Wayland) maintains a backbuffer for every (top-level) window instead of communicating “damage” back to applications. That seems to be its very thing—there’s a distinct feeling of “look what computers let us do now” in the papers. I don’t think it knows anything about the widgets inside those windows, either (again unlike classic X and like Wayland). (On the other hand, like classic X and unlike Wayland, it makes the client funnel every drawing operation through the window system.)
        wnoise 4y ago
        X also had "backing store", but there were reasons it was not very useful in practice.
  - KerrAvon 4y ago
    I don’t understand this comment. Wayland has already been mentioned. macOS and Windows have both also made huge progress in this area. And iOS is the gold standard for modern UI responsiveness.
    - hedora 4y ago
      All of those have worse latency than DOS or X11 (even when the latter are configured to prevent tearing by adding latency) Memory, power and compute efficiency have also regressed badly vs. those systems. Carmack explains how if would be possible to have tear free, framerate level updates "if only" people would upgrade to 8MB of video ram and 100MB/sec busses. I'm old enough to remember the DOS days. On average, iOS apps are significantly less responsive than old 386 DOS, SDL or X11 programs.
      - mananaysiempre 4y ago
        > Carmack explains how if would be possible to have tear free, framerate level updates "if only" people would upgrade to 8MB of video ram and 100MB/sec busses. With 1280x1024x8@75Hz and a single blit per frame. For 32-bit colour like you have virtually everywhere these days, multiply that bandwidth by four; for a 2560x1600 screen like the one I’m writing this on, multiply further by three and a bit; (admittedly,) for 60Hz instead of 75Hz, multiply by 4/5. All in all, this laptop I’m sitting before needs a gigabyte per second to just barely sustain one blit per frame. And it needs a full framebuffer of video RAM (15M bytes) for the pretty security-message crossfade, probably at least a couple framebuffers per tab for the tiled renderer in the browser, something in that ballpark so that I can smoothly scroll through a PDF I’m reading and not wait for it to rasterize... If I open a Chinese webpage, how much video RAM for the subpixel-positioned glyph cache, I wonder? And remember, none of that OpenGL floating-point-colour nonsense, that would multiply both memory and bandwidth by three again. Carmack could have probably squeezed a smooth UI into a 8M main + 8M (16M?) video RAM, 100 MB/s machine at 800x600, if the UI you wanted was the one from 1995. And that would honestly be grand, I’d be happy to see that on a 2005-specced machine, even. But let’s not kid ourselves—we do in fact demand much more from our computers now than we did then.
      - 4y ago
mananaysiempre 4y ago
Nope, much like 9p itself[1] the /dev/draw protocol[2] is a stream of (simple) binary records. And it’s not that the implicit separation is essential for parsing it, it’s that the servers don’t care to implement the additional buffering necessary in case a single message spans several read()s. (I still don’t remember whether I looked at one of the /dev/draw implementations or at one of the 9p implementations when I was curious about the fiddly buffering question, sorry.) [1] http://man.cat-v.org/plan_9_3rd_ed/5/intro http://man.cat-v.org/plan_9_3rd_ed/5/intro [2] http://man.cat-v.org/plan_9_3rd_ed/3/draw http://man.cat-v.org/plan_9_3rd_ed/3/draw

pjmlp 4y ago

Have some fun reading about Carmack's point of view on Plan 9 graphics. https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4

hulitu 4y ago
> Have some fun reading about Carmack's point of view on Plan 9 graphics. > https://marc.info/?a=111558719100068&r=1&w=4 https://marc.info/?a=111558719100068&r=1&w=4 > "Computers should feel instant whenever possible. This involves the event path, whatever processing is done, the speed of drawing, and the way the drawing is displayed." This was 27 years ago and still no progress on this field.
- zozbot234 4y ago
  Wayland and X compositors provide for tear-free video updates, which is what Carmack is talking about in those posts. Further progress will come from lowering the added latency, but that's a very different problem.
  - hedora 4y ago
    He goes on to complain about precursors to compositing. By the late 1990's Linux supported tear free with lower latency than compositors currently support. Anyway, computers have been getting worse at output latency since the mid 1980's. Compositing is just yet another ratcheted performance and usability regression.
    - zozbot234 4y ago
      Late-1990s systems supported practically tear-free updates for most practical uses, but AIUI there was not enough memory bandwidth for whole-screen updates to be tear-free, especially at higher resolutions and color depths. This is what Carmack is complaining about here. Even then, there are better and worse ways of coping with limited video memory bandwidth, and what's "best" depends on the given application.
      - hedora 4y ago
        According to Carmack (in 1995), tear free compatible PCI bandwidth was just starting to hit the market. This matches my memory of configuring tear free before y2k. I know for sure that I had tear free working at 1600x1200x24 (or 16?) by 2001.
    - mananaysiempre 4y ago
      FWIW, the Plan 9 window system is in fact a (very barebones) compositor in modern terms, in that it (unlike classic X and like Wayland) maintains a backbuffer for every (top-level) window instead of communicating “damage” back to applications. That seems to be its very thing—there’s a distinct feeling of “look what computers let us do now” in the papers. I don’t think it knows anything about the widgets inside those windows, either (again unlike classic X and like Wayland). (On the other hand, like classic X and unlike Wayland, it makes the client funnel every drawing operation through the window system.)
      - wnoise 4y ago
        X also had "backing store", but there were reasons it was not very useful in practice.
- KerrAvon 4y ago
  I don’t understand this comment. Wayland has already been mentioned. macOS and Windows have both also made huge progress in this area. And iOS is the gold standard for modern UI responsiveness.
  - hedora 4y ago
    All of those have worse latency than DOS or X11 (even when the latter are configured to prevent tearing by adding latency) Memory, power and compute efficiency have also regressed badly vs. those systems. Carmack explains how if would be possible to have tear free, framerate level updates "if only" people would upgrade to 8MB of video ram and 100MB/sec busses. I'm old enough to remember the DOS days. On average, iOS apps are significantly less responsive than old 386 DOS, SDL or X11 programs.
    - mananaysiempre 4y ago
      > Carmack explains how if would be possible to have tear free, framerate level updates "if only" people would upgrade to 8MB of video ram and 100MB/sec busses. With 1280x1024x8@75Hz and a single blit per frame. For 32-bit colour like you have virtually everywhere these days, multiply that bandwidth by four; for a 2560x1600 screen like the one I’m writing this on, multiply further by three and a bit; (admittedly,) for 60Hz instead of 75Hz, multiply by 4/5. All in all, this laptop I’m sitting before needs a gigabyte per second to just barely sustain one blit per frame. And it needs a full framebuffer of video RAM (15M bytes) for the pretty security-message crossfade, probably at least a couple framebuffers per tab for the tiled renderer in the browser, something in that ballpark so that I can smoothly scroll through a PDF I’m reading and not wait for it to rasterize... If I open a Chinese webpage, how much video RAM for the subpixel-positioned glyph cache, I wonder? And remember, none of that OpenGL floating-point-colour nonsense, that would multiply both memory and bandwidth by three again. Carmack could have probably squeezed a smooth UI into a 8M main + 8M (16M?) video RAM, 100 MB/s machine at 800x600, if the UI you wanted was the one from 1995. And that would honestly be grand, I’d be happy to see that on a 2005-specced machine, even. But let’s not kid ourselves—we do in fact demand much more from our computers now than we did then.
    - 4y ago

mananaysiempre 4y ago

Nope, much like 9p itself[1] the /dev/draw protocol[2] is a stream of (simple) binary records. And it’s not that the implicit separation is essential for parsing it, it’s that the servers don’t care to implement the additional buffering necessary in case a single message spans several read()s. (I still don’t remember whether I looked at one of the /dev/draw implementations or at one of the 9p implementations when I was curious about the fiddly buffering question, sorry.) [1] http://man.cat-v.org/plan_9_3rd_ed/5/intro http://man.cat-v.org/plan_9_3rd_ed/5/intro [2] http://man.cat-v.org/plan_9_3rd_ed/3/draw http://man.cat-v.org/plan_9_3rd_ed/3/draw