Spriteful TErminal GrAphics Protocol: Difference between revisions
No edit summary |
|||
| Line 32: | Line 32: | ||
Were it not for the need to avoid embedded ESC characters, communicating the graphic's geometry would be sufficient to avoid any need for further encoding. Unfortunately, we've assumed that an ESC (decimal 27) will abort the graphic. Most protocols use base64 encoding to work around this, resulting in a flat 33% increase in bytes transmitted. STEGAP instead defines a byte of 25 to be an internal escape. The byte following a 25 (0x19) byte can have only two values: 0 (to indicate 25), or 1 (to indicate 27). This is a 100% increase in bytes transmitted for 2 of 256 possible byte values. The best case is thus 0% overhead (no 25 nor 27 values), the expected overhead for a uniform distribution of bytes is 0.78%, there is less overhead until at least 33% of all values are 25 or 27, and the (pathological) worst case suffers 100% overhead. | Were it not for the need to avoid embedded ESC characters, communicating the graphic's geometry would be sufficient to avoid any need for further encoding. Unfortunately, we've assumed that an ESC (decimal 27) will abort the graphic. Most protocols use base64 encoding to work around this, resulting in a flat 33% increase in bytes transmitted. STEGAP instead defines a byte of 25 to be an internal escape. The byte following a 25 (0x19) byte can have only two values: 0 (to indicate 25), or 1 (to indicate 27). This is a 100% increase in bytes transmitted for 2 of 256 possible byte values. The best case is thus 0% overhead (no 25 nor 27 values), the expected overhead for a uniform distribution of bytes is 0.78%, there is less overhead until at least 33% of all values are 25 or 27, and the (pathological) worst case suffers 100% overhead. | ||
If this worst possible case is unacceptable, the semantics of the byte following a 25 could be expanded such that a new escape character was specified, but this seems kinda silly (and wouldn't help if the pixels are being generated on the fly, anyway). | |||
==Terminal obligations== | ==Terminal obligations== | ||
A change to the cell-pixel geometry (the geometry, in pixels, of a terminal cell) must result in a <tt>SIGWINCH</tt>, just as a change to the overall visible geometry does. The <tt>TIOCGWINSZ</tt> <tt>ioctl(2)</tt> must accurately fill in the <tt>ws_xpixel</tt> and <tt>ws_ypixel</tt> fields. | A change to the cell-pixel geometry (the geometry, in pixels, of a terminal cell) must result in a <tt>SIGWINCH</tt>, just as a change to the overall visible geometry does. The <tt>TIOCGWINSZ</tt> <tt>ioctl(2)</tt> must accurately fill in the <tt>ws_xpixel</tt> and <tt>ws_ypixel</tt> fields. | ||