Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:08 UTC (Wed) by nybble41 (subscriber, #55106)
In reply to: Wayland - Beyond X (The H) by khim
Parent article: Wayland - Beyond X (The H)

Seriously, we get it--though I'm not sure you do. You hate escape sequences and think it makes more sense to give TUI program direct low-level access to the terminal--write this string at this location in this style, poll for input events, etc.

Well, perhaps that does make more sense, at least for TUI applications. (For normal command-line programs its obviously a step backward, since there is no easy way to recover the original text once it's been formatted into a terminal buffer.) However, it could be done with a trivial network-transparent protocol just as easily as with a shared memory buffer. The important point is having low-level access to a very thin terminal, not how you communicate with it. Shared memory is faster due to being zero-copy (though not necessarily by a large margin), while message-passing has fewer locking issues and works better when latency is high. You can always convert one form into the other, though going from shared memory to message-passing tends to much less efficient since the original structure is not preserved.

P.S. TUIs are almost entirely an anachronism by this point. The systems which make regular use of text terminals use them mainly for CLIs, not TUIs, and many of these CLI programs are designed for serialized I/O. If you want low-level access, including direct access to the screen and input events, write a GUI. It really doesn't make sense to design applications around raw VGA-style text buffers only to run them in a terminal emulator running inside X.

to post comments

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:17 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

by the way, you can run into similar formatting problems with direct screen access if you make the mistake of outputting a character to the bottom right of the screen and let the screen scroll on you.

if you just do direct I/O to the screen, character by character you don't have this problem, but you can run into the problem that a badly written program starts scribbling on whatever is in memory right after the screen.

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:25 UTC (Wed) by khim (subscriber, #9252) [Link]

by the way, you can run into similar formatting problems with direct screen access if you make the mistake of outputting a character to the bottom right of the screen and let the screen scroll on you.

How? Direct screen access just puts your character there? To scroll the buffer you need completely another function.

if you just do direct I/O to the screen, character by character you don't have this problem, but you can run into the problem that a badly written program starts scribbling on whatever is in memory right after the screen.

You have this problem in any protocol with shared memory. That's what memory protection is for :-)

Wayland - Beyond X (The H)

Posted Feb 15, 2012 22:32 UTC (Wed) by khim (subscriber, #9252) [Link] (3 responses)

Seriously, we get it--though I'm not sure you do.

I'm not sure you get my point.

You hate escape sequences and think it makes more sense to give TUI program direct low-level access to the terminal--write this string at this location in this style, poll for input events, etc.

Not just for TUI. GUI, too.

However, it could be done with a trivial network-transparent protocol just as easily as with a shared memory buffer.

This is not proven. Most network-transparent protocols lead for the mess both in TUI and GUI case. My point is: if we can not even handle simple case (TUI) then what hope is there for more complex case (GUI)? If TUI suffers from the introduction of “effective network-transparency layer” then why don't you expect the similar effect on GUI? And if said transparency layer is actually damaging then are we even sure it's good idea to make it non-optional component?

Wayland - Beyond X (The H)

Posted Feb 15, 2012 23:16 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (2 responses)

> Not just for TUI. GUI, too. ... Most network-transparent protocols lead for the mess both in TUI and GUI case.

I'm not seeing that at all. Your examples all come from the legacy serial terminal and its escape codes, and do not apply to GUIs. Elsewhere you did state that "When you see garbage in your console and when you see overlapping text in your [remotely served] Firefox it's the exact same failure", but (a) I've never seen that kind of failure, and (b) even presuming it exists, it doesn't really seem like the same thing at all.

> If TUI suffers from the introduction of “effective network-transparency layer” ...

But it doesn't. TUI suffers from being forced to work through a protocol which was not "designed" so much as "evolved", in the very early stages of computer science, before we learned to design proper protocols, constantly merging features from similar-but-incompatible protocols and being extended and forked for various special cases. The implementation *is* the standard, and yet there is no single reference implementation. Given all of that, it's something of a wonder that it works at all.

I doubt a direct-access protocol would work as well--consider trying to write such a TUI when there is no standard memory layout, color/style encoding, character encoding, input API, etc. That interface is simpler only because it is standardized. If you ignored the issue of legacy compatibility, and simply defined what you want the terminal to do (perhaps based on the Windows terminal API), you can trivially provide a well-defined way to serialize those commands into a stream of messages which will achieve the same effect without any of the problems you've described.

> ... if we can not even handle simple case (TUI) then what hope is there for more complex case (GUI)? ... why don't you expect the similar effect on GUI?

Basically, because the GUI case (both for X11, and even more so for whatever remoting protocol is used with Wayland) is not nearly so encumbered by the need to remain compatible with legacy clients. There are actual independent standards involved. X11 has some legacy clients to deal with, but the original protocol was still much better defined than "serial communications with ANSI/VT100/xterm escape codes". The Wayland remoting protocol is in an even better position to adopt a rational design.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 1:10 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

>I'm not seeing that at all. Your examples all come from the legacy serial terminal and its escape codes, and do not apply to GUIs.

They do. The whole X-Windows uses exactly the same architecture - series of 'escape codes' over a serial line (Unix socket or TCP pipe). And the same argument apply - X works poorly both in remote AND in local cases.

Wayland - Beyond X (The H)

Posted Feb 16, 2012 15:29 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> The whole X-Windows uses exactly the same architecture - series of 'escape codes' over a serial line (Unix socket or TCP pipe).

That is a gross oversimplification. Yes, they both use serial protocols. Most things do nowadays. However, X11 doesn't use "escape codes"; the protocol is designed around structured messages with clear boundaries. More importantly, each X client has its own state and an independent connection to the X server, so they can access the screen and input without conflict. The problem you described are an artifact of the particular set of protocols used for serial terminals, not serialized protocols in general.

> And the same argument apply - X works poorly both in remote AND in local cases.

To say it works "poorly" in either case is another exaggeration. For what it was originally designed for, it works just fine. Technology has moved on, of course, and the prevalence of client-side rendering means that we now have rather different requirements for efficient rendering than we used to. The core rendering protocol is mostly unused, clients tend to provide pre-rendered buffers, the addition of compositing support means an extra round-trip, etc. However, I don't believe I've _ever_ seen the kinds of problems in X which you've described for TUI applications.