@xterm/addon-image 0.10.0-beta.268 → 0.10.0-beta.269

package/README.md

@@ -90,7 +90,7 @@ terminal.loadAddon(imageAddon);
   therefore palette animations cannot be used.
 
 - **SIXEL Raster Attributes Handling**  
-  If raster attributes were found in the SIXEL data (level 2), the image will always be truncated to the given height/width extend. We deviate here from the specification on purpose, as it allows several processing optimizations. For level 1 SIXEL data without any raster attributes the image can freely grow in width and height up to the last data byte, which has a much higher processing penalty. In general encoding libraries should not create level 1 data anymore and should not produce pixel information beyond the announced height/width extend. Both is discouraged by the >30 years old specification.
+  If raster attributes were found in the SIXEL data (level 2), the image will always be truncated to the given height/width extent. We deviate here from the specification on purpose, as it allows several processing optimizations. For level 1 SIXEL data without any raster attributes the image can freely grow in width and height up to the last data byte, which has a much higher processing penalty. In general encoding libraries should not create level 1 data anymore and should not produce pixel information beyond the announced height/width extent. Both is discouraged by the >30 years old specification.
 
   Currently the SIXEL implementation of the addon does not take custom pixel sizes into account, a SIXEL pixel will map 1:1 to a screen pixel.
 
@@ -149,9 +149,9 @@ The addon provides the following API endpoints to retrieve raw image data as can
 
 ### Memory Usage
 
-The addon does most image processing in Javascript and therefore can occupy a rather big amount of memory. To get an idea where the memory gets eaten, lets look at the data flow and processing steps:
-- Incomming image data chunk at `term.write` (terminal)  
-  `term.write` might stock up incoming chunks. To circumvent this, you will need proper flow control (see xterm.js docs). Note that with image output it is more likely to run into this issue, as it can create lots of MBs in very short time.
+The addon does most image processing in JavaScript and therefore can occupy a rather big amount of memory. To get an idea where the memory gets eaten, let's look at the data flow and processing steps:
+- Incoming image data chunk at `term.write` (terminal)  
+  `term.write` might stack up incoming chunks. To circumvent this, you will need proper flow control (see xterm.js docs). Note that with image output it is more likely to run into this issue, as it can create lots of MBs in very short time.
 - Sequence Parser (terminal)  
   The parser operates on a buffer containing up to 2^17 codepoints (~0.5 MB).
 - Sequence Handler - Chunk Decoding (addon)  
@@ -177,18 +177,18 @@ const totalActive = storageBytes + decodingBytes;
 ```
 
 Note that browsers have offloading tricks for rarely touched memory segments, esp. `storageBytes` might not directly translate into real memory usage. Usage peaks will happen during active decoding of multiple big images due to the need of 2 full pixel buffers at the same time, which cannot be offloaded. Thus you may want to keep an eye on `pixelLimit` under limited memory conditions.  
-Further note that the formulas above do not respect the Javascript object's overhead. Compared to the raw buffer needs the book keeping by these objects is rather small (<<5%).
+Further note that the formulas above do not respect the JavaScript object's overhead. Compared to the raw buffer needs the bookkeeping by these objects is rather small (<<5%).
 
 _Why should I care about memory usage at all?_  
-Well you don't have to, and it probably will just work fine with the addon defaults. But for bigger integrations, where much more data is held in the Javascript context (like multiple terminals on one page), it is likely to hit the engine's memory limit sooner or later under decoding and/or storage pressure.
+Well you don't have to, and it probably will just work fine with the addon defaults. But for bigger integrations, where much more data is held in the JavaScript context (like multiple terminals on one page), it is likely to hit the engine's memory limit sooner or later under decoding and/or storage pressure.
 
 _How can I adjust the memory usage?_  
 - `pixelLimit`  
-  A constructor setting, thus you would have to anticipate, whether (multiple) terminals in your page gonna do lots of concurrent decoding. Since this is normally not the case and the memory usage is only temporarily peaking, a rather high value should work even with multiple terminals in one page.
+  A constructor setting, thus you would have to anticipate, whether (multiple) terminals in your page gonna do lots of concurrent decoding. Since this is normally not the case and the memory usage only peaks temporarily, a rather high value should work even with multiple terminals in one page.
 - `storageLimit`  
-  A constructor and a runtime setting. In conjunction with `storageUsage` you can do runtime checks and adjust the limit to your needs. If you have to lower the limit below the current usage, images will be removed in FIFO order and may turn into a placeholder in the terminal's scrollback (if `showPlaceholder` is set). When adjusting keep in mind to leave enough room for memory peaking for decoding.
+  A constructor and a runtime setting. In conjunction with `storageUsage` you can do runtime checks and adjust the limit to your needs. If you have to lower the limit below the current usage, images will be removed in FIFO order and may turn into a placeholder in the terminal's scrollback (if `showPlaceholder` is set). When adjusting keep in mind to leave enough room for peak memory use during decoding.
 - `sixelSizeLimit | iipSizeLimit | kittySizeLimit`  
-  Constructor settings. This has only a small impact on peaking memory during decoding. It is meant to avoid processing of overly big or broken image sequences at an earlier phase, thus may stop the invoked decoders from entering memory intensive tasks for potentially invalid data.
+  Constructor settings. This has only a small impact on peak memory during decoding. It is meant to avoid processing of overly big or broken image sequences at an earlier phase, thus may stop the invoked decoders from entering memory intensive tasks for potentially invalid data.
 
 
 ### Terminal Interaction

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xterm/addon-image",
-  "version": "0.10.0-beta.268",
+  "version": "0.10.0-beta.269",
   "author": {
     "name": "The xterm.js authors",
     "url": "https://xtermjs.org/"
@@ -27,8 +27,8 @@
     "sixel": "^0.16.0",
     "xterm-wasm-parts": "^0.4.1"
   },
-  "commit": "4226e64245bbf0612a94d81c907fe11cf1065b9a",
+  "commit": "0b6fd2e8b2ee5bdaf6607076f6fae3b2e4ea0d44",
   "peerDependencies": {
-    "@xterm/xterm": "^6.1.0-beta.268"
+    "@xterm/xterm": "^6.1.0-beta.269"
   }
 }