Spriteful TErminal GrAphics Protocol: Difference between revisions

Line 31:

If the terminal emulator cannot fully implement RGBA for some reason (perhaps it has only 256 colors at its disposal), it ought itself sensibly quantize the graphic. Likewise, in the absence of composed translucency, the Alpha channel can be partitioned into a wholly transparent range and a wholly opaque range. <b>It is mandatory that a pixel with an Alpha value of 0 not obscure an existing pixel</b>.

~~The~~ graphic's geometry is ~~always communicated first~~, as a ~~mandatory part of~~ the ~~control sequence~~.

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.

==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.

@@ Line 31: / Line 31: @@
 If the terminal emulator cannot fully implement RGBA for some reason (perhaps it has only 256 colors at its disposal), it ought itself sensibly quantize the graphic. Likewise, in the absence of composed translucency, the Alpha channel can be partitioned into a wholly transparent range and a wholly opaque range. <b>It is mandatory that a pixel with an Alpha value of 0 not obscure an existing pixel</b>.
-The graphic's geometry is always communicated first, as a mandatory part of the control sequence.
+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.
+==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.

Spriteful TErminal GrAphics Protocol: Difference between revisions

Dank (talk | contribs)