add build (code) artifacts to main

azure/docsite/api/api-c-d2d/index.html

@@ -1249,19 +1249,19 @@ <h2 id="examples">Examples</h2>
 </tbody>
 </table>
 <h2 id="overview">Overview</h2>
-<p>Add a canvas tag to your HTML named <code>twr_d2dcanvas</code> like this example (you can use any width/height you like):</p>
+<p>To create a canvas surface that you can draw to using the twr-wasm 2D C drawing APIs, add a canvas tag to your HTML named <code>twr_d2dcanvas</code> like this example (you can use any width/height you like):</p>
 <div class="language-text highlight"><pre><span></span><code><span id="__span-0-1"><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>&lt;canvas id=&quot;twr_d2dcanvas&quot; width=&quot;600&quot; height=&quot;600&quot;&gt;&lt;/canvas&gt;
 </span></code></pre></div>
 <p>To draw using the C 2D Draw API:</p>
 <ul>
-<li>call d2d_start_draw_sequence()</li>
-<li>call draw commands, like d2d_fillrect()</li>
-<li>call d2d_end_draw_sequence()</li>
+<li>call <code>d2d_start_draw_sequence</code></li>
+<li>call one or more (a sequence) of 2D draw commands, like <code>d2d_fillrect</code></li>
+<li>call <code>d2d_end_draw_sequence</code></li>
 </ul>
-<p>Commands are queued until flushed, which will take the batch of queued draw commands, and execute them.  In the case of twrWasmModuleAsync, the batch of commands is sent over to the JavaScript main thread for execution. By batching the calls, performance is improved.</p>
-<p>Flush() waits for the commands to finish execution before returning.  Flush() is called automatically by d2d_end_draw_sequence() and so you generally don't need to call it manually.</p>
-<p>You pass an argument to d2d_start_draw_sequence() specifying how many instructions will trigger an automatic flush.  You can make this larger for efficiency, or smaller if you want to see the render progress with more frequently.  There is no limit on the size of the queue, except memory used in the Wasm module.  There is a flush() function that you can manually call, but it is not normally needed, unless you would like to ensure a sequence renders before d2d_end_draw_sequence() is called, or before the count passed d2d_start_draw_sequence() is met.</p>
-<p>If you are using twrWasmModuleAsync, or if you are re-rendering the entire frame for each animation update, you should ensure that all of your draws for a single complete frame are made without a call to flush() in the middle of the draw operations, as this may cause flashing.</p>
+<p>Commands are queued until flushed --  which will take the batch of queued draw commands, and execute them.  The 2D draw APIs will work with either <code>twrWasmModule</code> or <code>twrWasmModuleAsync</code>.   With <code>twrWasmModuleAsync</code>, the batch of commands is sent from the worker thread over to the JavaScript main thread for execution. By batching the calls between calls to <code>d2d_start_draw_sequence</code> and <code>d2d_end_draw_sequence</code>, performance is improved.</p>
+<p><code>d2d_flush</code> waits for the commands to finish execution before returning.  <code>d2d_flush</code> is called automatically by <code>d2d_end_draw_sequence</code> and so you generally don't need to call it manually.</p>
+<p>You pass an argument to <code>d2d_start_draw_sequence</code> specifying how many instructions will trigger an automatic call to <code>d2d_flush</code>.  You can make this larger for efficiency, or smaller if you want to see the render progress more frequently.  There is no limit on the size of the queue, except memory used in the Wasm module.  The <code>d2d_flush</code> function can be called manually call, but this is not normally needed, unless you would like to ensure a sequence renders before your <code>d2d_end_draw_sequence</code> is called, or before the count passed <code>d2d_start_draw_sequence</code> is met.</p>
+<p>If you are using <code>twrWasmModuleAsync</code>, or if you are re-rendering the entire frame for each animation update, you should ensure that all of your draws for a complete frame are made without an explicit or implicit call to <code>d2d_flush</code> in the middle of the draw sequence, as this may cause flashing.</p>
 <h2 id="functions">Functions</h2>
 <p>These are the Canvas APIs currently available in C:</p>
 <div class="language-text highlight"><pre><span></span><code><span id="__span-1-1"><a id="__codelineno-1-1" name="__codelineno-1-1" href="#__codelineno-1-1"></a>struct d2d_draw_seq* d2d_start_draw_sequence(int flush_at_ins_count);

azure/docsite/gettingstarted/parameters/index.html

@@ -1302,15 +1302,17 @@ <h1 id="passing-function-parameters-to-webassembly">Passing Function Parameters
 <h2 id="webassembly-virtual-machine-intrinsic-capabilities">WebAssembly Virtual Machine Intrinsic Capabilities</h2>
 <p>The WebAssembly VM (often referred to as a Wasm “Runtime”) is limited to passing numbers between C functions and the Wasm host (I’ll assume that’s JavaScript for this document). In other words, if you are using the most basic WebAssembly capabilities provided by JavaScript, such as <code>WebAssembly.Module</code>, <code>WebAssembly.Instance</code>, and <code>instance.exports</code>, your function calls and return types can only be:</p>
 <ul>
-<li>Integer 32 bit</li>
+<li>Integer 32 or 64 bit</li>
 <li>Floating point 32 or 64 bit</li>
 </ul>
-<p>The WebAssembly spec supports: i32, i64, f32, and f64. But JavaScript doesn’t support 64-bit integers without using the <code>BigInt</code> type. The JavaScript Number is always a <code>Float64</code>, known as a “double” in C/C++. A JavaScript Number can be converted to a <code>Float32</code> or an <code>Integer32</code>.</p>
-<p>When using 32-bit WebAssembly (by far the most common default), and you call a C function from JavaScript without using any “helper” libraries, the following parameter types can be passed:</p>
+<p>These correspond to the WebAssembly spec support for: i32, i64, f32, and f64. </p>
+<p>Note that a JavaScript <code>number</code> is of type Float 64 (known as a <code>double</code> in C/C++.).  If you are storing an integer into a JavaScript <code>number</code>, it is converted to a Float 64, and its maximum "integer" precision is significantly less than 64 bits (its about 52 bits, but this a simplification).  As a result, to use a 64-bit integers with JavaScript the <code>bigint</code> type is used. </p>
+<p>When using 32-bit WebAssembly (by far the most common default), and you call a C function from JavaScript without using any “helper” libraries (like twr-wasm), the following parameter types can be passed:</p>
 <ul>
-<li>Integer 32: JavaScript <code>Number</code> type is converted to an <code>Integer32</code> and passed to C when the C function prototype specifies a signed or unsigned int, long, int32_t, or a pointer type. All of these are 32 bits in length in wasm32.</li>
-<li>JavaScript <code>Number</code> type is passed as a <code>Float64</code> when the C function prototype specifies a double.</li>
-<li>JavaScript <code>Number</code> type is converted to a Float32 when the C function prototype specifies a float.</li>
+<li>Integer 32: JavaScript <code>number</code> type is converted to an Integer 32 and passed to C when the C function prototype specifies a <code>signed or unsigned int</code>, <code>long</code>, <code>int32_t</code>, or a pointer type. All of these are 32 bits in length in wasm32.</li>
+<li>Integer 64: JavaScript <code>bigint</code> type is converted to an Integer 64 and passed to C when the C function prototype specifies signed or unsigned <code>int64_t</code> (or equivalent).</li>
+<li>Float 32: JavaScript <code>number</code> type is converted to a Float 32 when the C function prototype specifies a <code>float</code>.</li>
+<li>Float 64: JavaScript <code>number</code> type is passed as a Float 64 when the C function prototype specifies a <code>double</code>.</li>
 </ul>
 <p>The same rules apply to the return types.</p>
 <h2 id="passing-strings-from-javascript-to-cc-webassembly">Passing Strings from JavaScript to C/C++ WebAssembly</h2>
@@ -1344,7 +1346,7 @@ <h2 id="returning-a-string-from-cc-webassembly-to-javascript">Returning a String
 <div class="language-js highlight"><pre><span></span><code><span id="__span-3-1"><a id="__codelineno-3-1" name="__codelineno-3-1" href="#__codelineno-3-1"></a><span class="kd">const</span><span class="w"> </span><span class="nx">retStringPtr</span><span class="w"> </span><span class="o">=</span><span class="w"> </span><span class="k">await</span><span class="w"> </span><span class="nx">mod</span><span class="p">.</span><span class="nx">callC</span><span class="p">([</span><span class="s2">&quot;ret_string_function&quot;</span><span class="p">]);</span>
 </span><span id="__span-3-2"><a id="__codelineno-3-2" name="__codelineno-3-2" href="#__codelineno-3-2"></a><span class="nx">console</span><span class="p">.</span><span class="nx">log</span><span class="p">(</span><span class="nx">mod</span><span class="p">.</span><span class="nx">getString</span><span class="p">(</span><span class="nx">retStringPtr</span><span class="p">));</span>
 </span></code></pre></div>
-<p>The <code>retStringPtr</code> is an integer 32 (but converted to a JavaScript <code>Number</code>, which is <code>Float64</code>). This integer is an index into the WebAssembly Memory.</p>
+<p>The <code>retStringPtr</code> is an integer 32 (but converted to a JavaScript <code>number</code>, which is Float 64). This integer is an index into the WebAssembly Memory.</p>
 <h2 id="passing-structs-from-javascript-to-cc-webassembly">Passing Structs from JavaScript to C/C++ WebAssembly</h2>
 <p>To pass a C struct (or receive a C struct), the same techniques used for strings can be used. The primary new complexity is that each struct entry’s memory address needs to be calculated. And when calculating the WebAssembly Memory indices for the struct entries, C structure padding must be accounted for. </p>
 <p>In clang, if you declare this structure in your C code:</p>
@@ -1365,7 +1367,7 @@ <h2 id="passing-structs-from-javascript-to-cc-webassembly">Passing Structs from
 <li>short is 2 byte aligned</li>
 <li>pointers are 4 byte aligned</li>
 <li>int, long, int32_t are 4 byte aligned</li>
-<li>double (<code>Float 64</code>) is 8-byte aligned</li>
+<li>double (Float 64) is 8-byte aligned</li>
 </ul>
 <p>If you are not familiar with structure padding, there are many articles on the web.</p>
 <p>Alignment requirements are why twr-wasm <code>malloc</code> (and GCC <code>malloc</code> for that matter) aligns new memory allocations on an 8-byte boundary.</p>

azure/docsite/index.html

@@ -1327,7 +1327,7 @@
 
 <h1 id="learn-webassembly-with-twr-wasmdocumentation-and-examples">Learn WebAssembly with twr-wasm<br>Documentation and Examples</h1>
 <h2 id="easier-cc-webassembly">Easier C/C++ WebAssembly</h2>
-<p>Version 2.1.1</p>
+<p>Version 2.2.0</p>
 <p>twr-wasm is a simple, lightweight and easy to use library for building C/C++ WebAssembly code directly with clang. It solves some common use cases with less work than the more feature rich emscripten. </p>
 <p>twr-wasm is easy to understand, and has some great features. You can call blocking functions. You can input and print streaming character i/o to a <code>&lt;div&gt;</code> tag, use a <code>&lt;canvas&gt;</code> element as an ANSI terminal, and use 2D drawing apis (that are compatible with JavaScript Canvas APIs) to draw to a <code>&lt;canvas&gt;</code> element. </p>
 <p>twr-wasm allows you to run C/C++ code in a web browser. Legacy code, libraries, full applications, or single functions can be integrated with JavaScript and TypeScript.</p>

azure/docsite/more/wasm-problem/index.html

@@ -1136,14 +1136,14 @@ <h1 id="wasm-runtime-limitations">Wasm Runtime Limitations</h1>
 <p>HTML browsers can load a WebAssembly module, and execute it's bytecode in a virtual machine.  To create this bytecode (.wasm file) from C/C++,
 you compile your code using clang with the target code format being WebAssembly (aka Wasm) byte code. If you are not using a support library
 like twr-wasm or emscripten, there are a few issues that one immediately encounters trying to execute code that is more complicated than squaring a number.  </p>
-<p>The Wasm virtual machine simply executes the instructions that are generated by the clang compiler and linked by the linker into the .wasm file.  The first issue ecountered is that some code that is generated by a compiler assumes a compiler support library will be linked to your code.  That is, clang code generation will produce calls to compiler support routines for floating point, memcpy, and the like. In clang, these support routines are
+<p>The Wasm virtual machine simply executes the instructions that are generated by the clang compiler and linked by the linker into the .wasm file.  The first issue encountered is that some code that is generated by a compiler assumes a compiler support library will be linked to your code.  That is, clang code generation will produce calls to compiler support routines for floating point, <code>memcpy</code>, and the like. In clang, these support routines are
 in the "compile-rt" support library.  Typically clang handles this behind to scenes for you.  But support for a WebAssembly version of this compiler support library is not (as of this writing) included in a clang distribution.</p>
-<p>The next level up the library stack is the standard C runtime library.  This library provides functions like malloc and  printf. And then built on the standard C runtime library is the standard c++ library -- like libc++.  WebAssembly versions of these libraries are also not part of a clang distribution.  </p>
+<p>The next level up the library stack is the standard C runtime library.  This library provides functions like <code>malloc</code> and  <code>printf</code>. And then built on the standard C runtime library is the standard c++ library - like libc++.  WebAssembly versions of these libraries are also not part of a clang distribution.  </p>
 <p>To get access to WebAssembly versions of these libraries you need to use emscripten or twr-wasm.</p>
 <p>The second problem is that all the function calls between your Wasm module and your javascript are limited to parameters and return values that are numbers (integer and float). No strings, arrays, struct pointers, etc. (for more on this see <a href="../../gettingstarted/parameters/">this doc</a>).</p>
 <p>The third problem is that legacy C code or games often block, and when written this way they don't naturally integrate with the JavaScript asynchronous programming model.</p>
 <p>twr-wasm is a static C library (twr.a) that you can link to your clang C/C++ Wasm code, as well as a set of JavaScript/TypeScript modules that solve these issues.</p>
-<p>twr-wasm provides additional APIs that you can use in your WebAssembly code - such as Canvas compatible 2D drawing APIs, a simple ANSI terminal emulator, character encoding support, and more.</p>
+<p>In addition, twr-wasm provides APIs that you can use in your WebAssembly code - such as Canvas compatible 2D drawing APIs, a simple ANSI terminal emulator, character encoding support, and more.</p>