Add a spellchecking mode for sphinx and fix some typos

* The worst one was Persistant -> Persistent. This involved renaming PersistentConfig but the impact of that is considered minimal enough to be worth fixing.
2026-09-22 21:55:52 +00:00 · 2026-08-13 17:46:47 +01:00
parent 5e462c5ebe
commit bb4017a965
75 changed files with 653 additions and 248 deletions
@@ -60,6 +60,21 @@ sys.path.insert(0, os.path.abspath('sphinx_exts'))
 # ones.
 extensions = ['sphinx.ext.autodoc', 'sphinx_paramlinks', 'sphinxcontrib_jquery']

+if tags.has('spelling'): # type: ignore
+    extensions.append('sphinxcontrib.spelling')
+    spelling_lang = tokenizer_lang = 'en_US'
+    spelling_show_suggestions = True
+    spelling_exclude_patterns = ['credits_*']
+    spelling_word_list_filename = [
+            # for personal ease and to avoid too many renames, british english words
+            # as well as a few english words not in the spelling dictionary
+            'spelling_english.txt',
+            # graphics-specific terms or proper nouns
+            'spelling_graphics.txt',
+            # more general technology language or terms
+            'spelling_general.txt'
+        ]
+
 # Add any paths that contain templates here, relative to this directory.
 templates_path = ['_templates']

@@ -47,7 +47,7 @@ In particular I'm used to working with people who have strong NDA protection ove
 How can I associate RenderDoc's file extensions with the program?
 -----------------------------------------------------------------

-On Windows if you installed RenderDoc via the msi installer, the option is available there to associate RenderDoc's file extensions with the program.
+On Windows if you installed RenderDoc via the ``msi`` installer, the option is available there to associate RenderDoc's file extensions with the program.

 On linux the binary tarball comes with files to place under ``/usr/share`` to associate RenderDoc with files. This obviously also requires ``qrenderdoc`` to be available in your ``PATH``.

@@ -125,7 +125,7 @@ For other textures it's more difficult - for starters they may actually contain

 Nothing is actually wrong here except perhaps that when visualising linear data it is often more convenient to "over-correct" such that the data is perceptually linear. A good example to use is a normal map: The classic deep blue of (127,127,255) flat normals is technically incorrect as everyone is used to visualising these textures in programs that display the data as if it were sRGB (which is the convention for normal images that do not represent vectors).

-You can override this behaviour on any texture that isn't listed as explicitly sRGB with the gamma (γ) button - toggle this off and the over-correction will be disabled.
+You can override this behaviour on any texture that isn't listed as explicitly sRGB with the gamma (``γ``) button - toggle this off and the over-correction will be disabled.

 RenderDoc makes my bug go away! Or causes new artifacts that weren't there
 --------------------------------------------------------------------------
@@ -50,8 +50,8 @@ Current Common Feature set
    * Currently set RT/textures thumbnail strip - updates as you move through the frame. Follows the currently selected pipeline slot as it changes, rather than remaining on the given texture.
    * Tabbed view for locking a view of a particular resource over time.
    * Pixel value picking.
-    * Save (in theory) any type of texture and format to various formats, dds as well as regular png/jpg.
-    * Several debug overlays for render targets - Wireframe, Depth pass/fail, Stencil pass/fail, Clipping (below black/above white points), NaN/-ve/INF highlight, quad overdraw, triangle size.
+    * Save (in theory) any type of texture and format to various formats, ``dds`` as well as regular ``png``/``jpg``.
+    * Several debug overlays for render targets - Wireframe, Depth pass/fail, Stencil pass/fail, Clipping (below black/above white points), NaN/negative/INF highlight, quad overdraw, triangle size.

 * Custom visualisation shader support - e.g. decode custom packed formats or gbuffers.
 * Hot shader editing and replacement.
@@ -14,7 +14,7 @@ To capture a frame, begin by selecting :guilabel:`File` → :guilabel:`Launch Ap

    Launching an executable

-The defaults work pretty well in most situations, so you can just either browse to or drag in your exe into the Executable box. If the working directory box is empty then the executable's directory will be used. Enter any command line you may need and click Launch to launch the application with RenderDoc.
+The defaults work pretty well in most situations, so you can just either browse to or drag in your executable file into the :guilabel:`Executable` box. If the :guilabel:`Working directory` box is empty then the executable's directory will be used. Enter any command line you may need and click Launch to launch the application with RenderDoc.

 More details of the specific options and their functionality can be found in the details page for the :doc:`../window/capture_attach`.

@@ -138,7 +138,7 @@ More details can be found on the :doc:`../window/timeline_bar` page.

 The timeline bar is essentially an alternate view of the frame, with the horizontal axis being time in the frame. The horizontal axis is scaled evenly by API calls, such that every API call has the same width at any given zoom level.

-The frame marker hierarchy is top-down in this case, and can be expanded or collapsed by clicking on each section. In this image, "Render Scene" and "Toon shading draw" are both expanded, but the other sections remain collapsed. Each action is rendered as a blue pip underneath the section of the hierarchy that it is a child of. The current action (if visible) is rendered as a green circle.
+The frame marker hierarchy is top-down in this case, and can be expanded or collapsed by clicking on each section. In this image, ``Render Scene`` and ``Toon shading draw`` are both expanded, but the other sections remain collapsed. Each action is rendered as a blue pip underneath the section of the hierarchy that it is a child of. The current action (if visible) is rendered as a green circle.

 There is a vertical line around the current action, as well as a |flag_green| above, and a gray outline around the event where the mouse is hovering.

@@ -56,7 +56,7 @@ Troubleshooting

 RenderDoc assumes your device is already configured for debugging. Check that it appears in ``adb devices``. `See here <https://developer.android.com/studio/run/device.html>`_ for instructions on how to configure that.

-If you have Android Studio open, it will interfere with RenderDoc's debugging by attaching to the package itself. Either close it or disable adb integration in "Tools → Android → Enable ADB integration".
+If you have Android Studio open, it will interfere with RenderDoc's debugging by attaching to the package itself. Either close it or disable ``adb`` integration in :guilabel:`Tools → Android → Enable ADB integration`.

 RenderDoc does its best to locate or provide necessary Android tools from the Android SDK. On Windows, these tools are shipped with the distributions and all that's required is java - either in your ``PATH`` or via the ``JAVA_HOME`` environment variable. If these tools aren't present then RenderDoc searches through ``PATH`` and other variables like ``ANDROID_HOME`` or ``ANDROID_SDK_ROOT`` to find the SDK. If you don't have those environment variables set, you can browse to the SDK and JDK folders in the :doc:`settings window <../window/settings_window>` under the :guilabel:`Android` section.

@@ -3,7 +3,7 @@ How do I specify a buffer format?

 This page documents how to format buffer data, in cases where the default reflected format is missing or you want to customise it.

-The format string can contain C and C++ style comments freely, but a C pre-processor is not supported.
+The format string can contain C and C++ style comments freely, but a C preprocessor is not supported.

 By default the final interpreted format is defined by the list of global variables in the layout string, however if no global variables are defined the final struct to be defined is used as-if there were a single variable instance of that struct.

@@ -198,7 +198,7 @@ Variable declarations support the following annotations:
 Array of Structs (AoS) vs Struct of Arrays (SoA)
 ------------------------------------------------

-The :doc:`../window/buffer_viewer` is capable of displaying both repeating data of a single format (AoS) as well as fixed non-repeating data (called SoA). Typically AoS is used for large buffers, where a small struct is repeated many times to form the elemnts in the buffer. SoA is used most commonly for constant buffers with a fixed amount of data, but can be used in any context. On some APIs it is possible for a buffer to contain some fixed data before the repeating data and thus it contains both types.
+The :doc:`../window/buffer_viewer` is capable of displaying both repeating data of a single format (AoS) as well as fixed non-repeating data (called SoA). Typically AoS is used for large buffers, where a small struct is repeated many times to form the elements in the buffer. SoA is used most commonly for constant buffers with a fixed amount of data, but can be used in any context. On some APIs it is possible for a buffer to contain some fixed data before the repeating data and thus it contains both types.

 RenderDoc tries to use context to interpret buffer formats correctly, defaulting to AoS interpretation in cases where it is likely intended. However this can be hinted or overridden as desired.

@@ -208,7 +208,7 @@ To specify AoS data explicitly you can declare an unbounded array:

  float3 unboundedArray[]; // unbounded array of float3s

-When supported by the API, this can be preceeded by any fixed data in the buffer before the repeated AoS data. The buffer viewer will show both parts of the data separately, with a tree view for the fixed data and a table for the repeated data.
+When supported by the API, this can be preceded by any fixed data in the buffer before the repeated AoS data. The buffer viewer will show both parts of the data separately, with a tree view for the fixed data and a table for the repeated data.

 In the opposite direction, normally a loose collection of variables without any such unbounded array will be taken as the definition of a struct within an AoS view:

@@ -10,7 +10,7 @@ It can be useful when tracking down problems to have an idea of where each API c

 .. warning::

-	On Windows the callstack gathering uses ``dbghelp.dll``. If you're using this dll for some other debugging functionality in your app it is highly recommended that you disable it, otherwise it can conflict and break RenderDoc's callstack capture.
+	On Windows the callstack gathering uses ``dbghelp.dll``. If you're using this DLL for some other debugging functionality in your app it is highly recommended that you disable it, otherwise it can conflict and break RenderDoc's callstack capture.

 .. note::

@@ -40,7 +40,7 @@ To resolve the symbols referenced in the capture, go to the :guilabel:`Tools` me

 The resolving symbols process may take some time the first few instances you use it, as it may have to download symbols from the Microsoft symbol server. Each module that is loaded in the application at the time of capture will be saved and its symbols searched for.

-By default a symbol server will be used, as well as a few default locations such as the location indicated in the PE metadata (i.e. the original build location). If a pdb cannot be found you will be prompted for the location of the pdb, and this new location will then be remembered for subsequent pdbs.
+By default a symbol server will be used, as well as a few default locations such as the location indicated in the PE metadata (i.e. the original build location). If a PDB cannot be found you will be prompted for the location of the PDB, and this new location will then be remembered for subsequent PDBs.

 .. figure:: ../imgs/Screenshots/NeedPDB.png

@@ -31,7 +31,7 @@ Injecting into a Process

 It is possible to inject to an already running process as long as it hasn't yet initialised a graphics API. By selecting :guilabel:`File` → :guilabel:`Inject to Process`, the capture dialog will modify to list the running processes rather than asking for an executable and command line parameters.

-This can be useful if launching your application from a single exe is non-trivial and it's easier to inject into the process after it has been launched.
+This can be useful if launching your application from a single executable file is non-trivial and it's easier to inject into the process after it has been launched.

 .. figure:: ../imgs/Screenshots/Injecting.png

@@ -329,7 +329,7 @@ GLSL
  #endif


-These resources are bound sparsely with the appropriate type for the current texture. With a couple of exceptions there will only be one texture bound at any one time. Different APIs have different texture type matching requirements, so e.g. OpenGL has separate bindings for array and non-array texures, which will be reflected in the different ``RD_TextureType`` return values.
+These resources are bound sparsely with the appropriate type for the current texture. With a couple of exceptions there will only be one texture bound at any one time. Different APIs have different texture type matching requirements, so e.g. OpenGL has separate bindings for array and non-array textures, which will be reflected in the different ``RD_TextureType`` return values.

 When a cubemap texture is bound, it is bound both to the 2D Array as well as the Cube Array. If a depth-stencil texture has both components, the relevant depth and stencil resources will both be bound at once.

@@ -98,7 +98,7 @@ Now we can see the pipeline and vertex/index buffer binds that happened before t
 Let's say that we only care about buffer bindings and want to exclude the pipeline bind. We could do this by adding a ``-Pipeline`` term, but we might then have to exclude other types of bindings and that could get tedious. Instead we'll change the bind term to ``(+Bind +Buffer)`` which will only match events that contain ``Bind`` and ``Buffer``. Since the term itself is optional, this still means actions are included.

 .. note::
-    This could be accomplished another way such as usuing a regular expression, but for the sake of example we'll do it like this.
+    This could be accomplished another way such as using a regular expression, but for the sake of example we'll do it like this.

 .. figure:: ../imgs/Screenshots/EventsFilteredBindBuffer.png

@@ -61,7 +61,7 @@ An example for this for linux would be to use ``plink.exe`` and passwordless key

    plink.exe user@host DISPLAY=:0.0 renderdoccmd remoteserver -d

-Assuming that plink.exe is in ``PATH`` on the host machine, and ``renderdoccmd`` is on the host machine.
+Assuming that ``plink.exe`` is in ``PATH`` on the host machine, and ``renderdoccmd`` is on the host machine.

 Switching to a Replay Context
 -----------------------------
@@ -57,7 +57,7 @@ More details on this section are available on the :doc:`../window/buffer_viewer`

 .. note::

-	This window supports copy and paste, so simply select the entries and ctrl-c to copy to the clipboard
+	This window supports copy and paste, so simply select the entries and :kbd:`Ctrl-C` to copy to the clipboard

 Viewing Constant Buffers
 ------------------------
@@ -72,4 +72,4 @@ Whenever this shader slot has a constant buffer in it, both the constant names a

 .. note::

-	This window supports copy and paste, so simply select the entries and ctrl-c to copy to the clipboard
+	This window supports copy and paste, so simply select the entries and :kbd:`Ctrl-C` to copy to the clipboard
@@ -20,13 +20,13 @@ Shader search paths

 In the RenderDoc settings menu, under the ``Core`` category, you can specify shader debug search paths. These are the directories that will be searched to find separated debug information based on a path in the original shader.

-Each path can be set as 'recursive' or not, with the default being to treat it as recursive. This is explained below in the search priority list, but generally should be turned off for network shares or very large folders where listing all contained files recusively would be slow. The paths can be rearranged to provide a priority order.
+Each path can be set as 'recursive' or not, with the default being to treat it as recursive. This is explained below in the search priority list, but generally should be turned off for network shares or very large folders where listing all contained files recursively would be slow. The paths can be rearranged to provide a priority order.

 When searching for separate debug info based on a path in the stripped shader blob, RenderDoc follows the following algorithm. This is based on trying to match PIX's behaviour which is the primary other tool that supports this, under the principle of least surprise. PIX's search algorithm is deliberately undocumented and so this has been determined by reverse engineering, some tweaks have been made for usability.

 .. note::

-  If the filename is proceeded by ``lz4#`` then this will be stripped before consideration and the file will be considered lz4 compressed. This is a RenderDoc extension only possible when using manually-specified shader blobs and is not currently supported by any compiler.
+  If the filename is proceeded by ``lz4#`` then this will be stripped before consideration and the file will be considered LZ4 compressed. This is a RenderDoc extension only possible when using manually-specified shader blobs and is not currently supported by any compiler.

 In this algorithm the original path from the shader is referred to as a 'filename', but it may contain relative path elements and may not be only a filename.

@@ -62,7 +62,7 @@ To do this you'll use your platforms dynamic library functions to see if the lib


    :param RENDERDOC_Version version: is the version number of the API for which you want the interface struct.
-    :param void** outAPIPointers: will be filled with the address of the API's function pointer struct, if supported. E.g. if ``eRENDERDOC_API_Version_1_1_1`` is requested, outAPIPointers will be filled with ``RENDERDOC_API_1_1_1*`` or any newer version that is compatible with API 1.1.1, but nothing lower.
+    :param void** outAPIPointers: will be filled with the address of the API's function pointer struct, if supported. E.g. if ``eRENDERDOC_API_Version_1_1_1`` is requested, ``outAPIPointers`` will be filled with ``RENDERDOC_API_1_1_1*`` or any newer version that is compatible with API 1.1.1, but nothing lower.
    :return: The function returns 1 if the API version is valid and available, and the struct pointer is filled. The function returns 0 if the API version is invalid or not supported, or the pointer parameter is invalid.

 .. cpp:function:: void GetAPIVersion(int *major, int *minor, int *patch)
@@ -122,7 +122,7 @@ To do this you'll use your platforms dynamic library functions to see if the lib

 .. cpp:enumerator:: RENDERDOC_CaptureOption::eRENDERDOC_Option_VerifyBufferWrites

-    specifies whether any mapped memory updates should be bounds-checked for overruns, and uninitialised buffers are initialised to 0xdddddddd to catch use of uninitialised data. Only supported on D3D11 and OpenGL. Default is off.
+    specifies whether any mapped memory updates should be bounds-checked for overruns, and uninitialised buffers are initialised to ``0xdddddddd`` to catch use of uninitialised data. Only supported on D3D11 and OpenGL. Default is off.

 .. cpp:enumerator:: RENDERDOC_CaptureOption::eRENDERDOC_Option_HookIntoChildren

@@ -280,8 +280,8 @@ To do this you'll use your platforms dynamic library functions to see if the lib

    This function modifies the current mask which determines what sections of the overlay render on each window.

-    :param uint32_t And: is a 32-bit value the mask is binary-AND'd with before processing ``Or``.
-    :param uint32_t Or: is a 32-bit value the mask is binary-OR'd with after processing ``And``.
+    :param uint32_t And: is a 32-bit value that will be combined using binary AND with the mask first, to remove bits.
+    :param uint32_t Or: is a 32-bit value that will be combined using binary OR with the mask second, to add bits.

 .. cpp:function:: void RemoveHooks()

@@ -107,6 +107,14 @@ if [ $1 == "html" ]; then
 	exit
 fi

+if [ $1 == "spelling" ]; then
+	"$SPHINXBUILD" -t spelling -b spelling $ALLSPHINXOPTS $BUILDDIR/spelling
+	if [ $? != 0 ]; then exit 1; fi
+	echo
+	echo "Build finished. The spelling pages are in $BUILDDIR/spelling."
+	exit
+fi
+
 if [ $1 == "dirhtml" ]; then
 	"$SPHINXBUILD" -b dirhtml $ALLSPHINXOPTS $BUILDDIR/dirhtml
 	if [ $? != 0 ]; then exit 1; fi
@@ -15,7 +15,7 @@ Build instructions for your platform are available `on github <https://github.co
  
  This can be overridden by setting an overridden path under the ``Python Configuration`` section in the properties of the ``qrenderdoc`` project and ``pyrenderdoc_module``/``qrenderdoc_module`` projects. It must point to a python installation.
  
-  RenderDoc requires pythonXY.lib, include files such as include/Python.h, as well as a .zip of the standard library. If you installed python with an installer you have the first two, and can generate the standard library zip by zipping the contents of the Lib folder. If you downloaded the embeddable zip distribution you will only have the standard library zip, you need to obtain the include files and ``.lib`` file separately.
+  RenderDoc requires ``pythonXY.lib``, include files such as include/Python.h, as well as a .zip of the standard library. If you installed python with an installer you have the first two, and can generate the standard library zip by zipping the contents of the Lib folder. If you downloaded the embeddable zip distribution you will only have the standard library zip, you need to obtain the include files and ``.lib`` file separately.

 Python Setup for VS Code
 ------------------------
@@ -17,7 +17,7 @@ Some methods like the two above return information which is global and does not

 During RenderDoc's replay, you can imagine a cursor that moves back and forth between the start and end of the frame. All requests for information that varies - such as texture and buffer contents, pipeline state, and other information will be relative to the current event.

-Every function call within a frame is assigned an ascending ``eventId``, from ``1`` up to as many events as are in the frame. Within the action list returned by :py:meth:`~renderdoc.ReplayController.GetRootActions`, each action contains a list of events in :py:attr:`~renderdoc.ActionDescription.events`. These contain all of the ``eventId`` that immediately preceeded the action. The details of the function call can be found by using :py:attr:`~renderdoc.APIEvent.chunkIndex` as an index into the structured data returned from :py:meth:`~renderdoc.GetStructuredFile`. The structured data contains the function name and the complete set of parameters passed to it, with their values.
+Every function call within a frame is assigned an ascending ``eventId``, from ``1`` up to as many events as are in the frame. Within the action list returned by :py:meth:`~renderdoc.ReplayController.GetRootActions`, each action contains a list of events in :py:attr:`~renderdoc.ActionDescription.events`. These contain all of the ``eventId`` that immediately preceded the action. The details of the function call can be found by using :py:attr:`~renderdoc.APIEvent.chunkIndex` as an index into the structured data returned from :py:meth:`~renderdoc.GetStructuredFile`. The structured data contains the function name and the complete set of parameters passed to it, with their values.

 To change the current active event and move the cursor, you can call :py:meth:`~renderdoc.ReplayController.SetFrameEvent`. This will move the replay to represent the current state immediately after the given event has executed.

@@ -7,7 +7,7 @@ In this example we will open a window and iterate through the capture on a loop,

    This is intended for use with the python module directly, as the UI already has a texture viewer panel to do this with much more control. The principle is the same though and it can be useful reference of how to iterate over a capture.

-To create a window we use tkinter, since it is provided with the Python distribution.
+To create a window we use ``tkinter``, since it is provided with the Python distribution.

 .. highlight:: python
 .. code:: python
@@ -19,7 +19,7 @@ To create a window we use tkinter, since it is provided with the Python distribu
    window = tkinter.Tk()
    window.geometry("1280x720")

-Next we need to determine which windowing systems the RenderDoc implementation supports, and create a :py:class:`~renderdoc.WindowingData` object for the window we want to render to. For the purposes of this example we will look for Win32 since it's the simplest to set up - needing only a window handle that we can get from tkinter easily. XCB/XLib require a display connection, which would be possible to get from another library such as Qt.
+Next we need to determine which windowing systems the RenderDoc implementation supports, and create a :py:class:`~renderdoc.WindowingData` object for the window we want to render to. For the purposes of this example we will look for Win32 since it's the simplest to set up - needing only a window handle that we can get from ``tkinter`` easily. ``XCB``/``XLib`` require a display connection, which would be possible to get from another library such as Qt.

 Once we have the :py:class:`~renderdoc.WindowingData`, we can create a :py:class:`~renderdoc.ReplayOutput` using :py:meth:`~renderdoc.ReplayController.CreateOutput`.

@@ -43,7 +43,7 @@ Once we have the :py:class:`~renderdoc.WindowingData`, we can create a :py:class
    # Create a texture output on the window
    out = controller.CreateOutput(windata, rd.ReplayOutputType.Texture)

-In order to iterate over all actions we need some global state first from :py:meth:`~renderdoc.ReplayController.GetTextures` and :py:meth:`~renderdoc.ReplayController.GetRootActions`, and we'll also define a helper function to fetch a particular texture by resourceId, so that we can easily look up the details for a texture.
+In order to iterate over all actions we need some global state first from :py:meth:`~renderdoc.ReplayController.GetTextures` and :py:meth:`~renderdoc.ReplayController.GetRootActions`, and we'll also define a helper function to fetch a particular texture by :class:`~renderdoc.ResourceId`, so that we can easily look up the details for a texture.

 .. highlight:: python
 .. code:: python
@@ -128,7 +128,7 @@ Finally we move to the next action in the list for the next time ``advance`` is
        else:
            window.after(50, advance)

-Once we have the callbacks defined, we call them once to initialise the display and set up the repeated callbacks, and start the tkinter main window loop.
+Once we have the callbacks defined, we call them once to initialise the display and set up the repeated callbacks, and start the ``tkinter`` main window loop.

 .. highlight:: python
 .. code:: python
@@ -20,7 +20,7 @@ For this section we assume you have built a copy of RenderDoc and have the modul
  
  This can be overridden by setting an overridden path under the ``Python Configuration`` section in the properties of the ``qrenderdoc`` project and ``pyrenderdoc_module``/``qrenderdoc_module`` projects. It must point to a python installation.
  
-  RenderDoc requires pythonXY.lib, include files such as include/Python.h, as well as a .zip of the standard library. If you installed python with an installer you have the first two, and can generate the standard library zip by zipping the contents of the Lib folder. If you downloaded the embeddable zip distribution you will only have the standard library zip, you need to obtain the include files and ``.lib`` file separately.
+  RenderDoc requires ``pythonXY.lib``, include files such as include/Python.h, as well as a .zip of the standard library. If you installed python with an installer you have the first two, and can generate the standard library zip by zipping the contents of the Lib folder. If you downloaded the embeddable zip distribution you will only have the standard library zip, you need to obtain the include files and ``.lib`` file separately.

 Once you have the module, either place the module within your python's default library search path, or else insert the location of the python module into the path in your script. You can either set the ``PYTHONPATH`` environment variable or do it at the start of your script:

@@ -20,7 +20,7 @@ On windows by default RenderDoc builds against python 3.6 which is what it's dis

 This can be overridden by setting an overridden path under the ``Python Configuration`` section in the properties of the ``qrenderdoc`` project and ``pyrenderdoc_module``/``qrenderdoc_module`` projects. It must point to a python installation.

-RenderDoc requires pythonXY.lib, include files such as include/Python.h, as well as a .zip of the standard library. If you installed python with an installer you have the first two, and can generate the standard library zip by zipping the contents of the Lib folder. If you downloaded the embeddable zip distribution you will only have the standard library zip, you need to obtain the include files and ``.lib`` file separately.
+RenderDoc requires ``pythonXY.lib``, include files such as include/Python.h, as well as a .zip of the standard library. If you installed python with an installer you have the first two, and can generate the standard library zip by zipping the contents of the Lib folder. If you downloaded the embeddable zip distribution you will only have the standard library zip, you need to obtain the include files and ``.lib`` file separately.

 .. note::

@@ -1,4 +1,4 @@
-API Reference: qrenderdoc Persistant Config
+API Reference: qrenderdoc Persistent Config
 ===========================================

 This is the API reference for the functions, classes, and enums in the ``qrenderdoc`` module which represents the UI-specific interface for integrating with the UI and writing UI extensions. For more high-level information and instructions on using the python API, see :doc:`../index` and :doc:`../ui_extensions`.
@@ -11,7 +11,7 @@ This is the API reference for the functions, classes, and enums in the ``qrender
 Config
 ------

-.. autoclass:: qrenderdoc.PersistantConfig
+.. autoclass:: qrenderdoc.PersistentConfig
  :members:

 .. autoclass:: qrenderdoc.TimeUnit
@@ -84,8 +84,8 @@ Pixel History
 .. autoclass:: PixelValue
  :members:

-Shader Debuging
---------------
+Shader Debugging
+----------------

 .. autoclass:: DebugPixelInputs
  :members:
@@ -164,6 +164,3 @@ Shader Messages

 .. autoclass:: renderdoc.ShaderComputeMessageLocation
  :members:
-
-
-* qrenderdoc.ShaderMessageViewer
@@ -79,7 +79,7 @@ First we create a class to handle our window and to derive from :py:class:`qrend
        def OnEventChanged(self, event):
            pass

-Here we implement stubs for the different events. More information on when they are sent can be found in the class documentation. We use the :py:class:`qrenderdoc.MiniQtHelper` to create a top-level window for ourselves with the 'breadcrumbs' title, then register oureslves as a capture viewer. The mini-Qt helper is useful to provide simple access to Qt widgets in a portable way from the RenderDoc UI, without relying on full Qt python bindings that may not be available depending on how RenderDoc was built.
+Here we implement stubs for the different events. More information on when they are sent can be found in the class documentation. We use the :py:class:`qrenderdoc.MiniQtHelper` to create a top-level window for ourselves with the 'breadcrumbs' title, then register ourselves as a capture viewer. The mini-Qt helper is useful to provide simple access to Qt widgets in a portable way from the RenderDoc UI, without relying on full Qt python bindings that may not be available depending on how RenderDoc was built.

 We will need to unregister ourselves as a capture viewer when the window is closed, which happens in the ``window_closed()`` callback that we'll define later.

@@ -0,0 +1,116 @@
+agnostically
+analyse
+analysing
+Analysing
+behaviour
+behaviours
+capitalisation
+capitalise
+categorisation
+categorised
+centre
+centred
+colour
+coloured
+colouring
+colourise
+colours
+Customimse
+customisable
+customisation
+customisations
+customise
+customised
+customising
+Customising
+emptively
+flavoured
+focussed
+greyscale
+hodge
+impactful
+initialisation
+Initialisation
+initialise
+Initialise
+initialised
+Initialised
+initialises
+Initialises
+initialising
+Initialising
+labelled
+Maths
+maximise
+maximising
+minimise
+misbehaviour
+natively
+neighbour
+neighbouring
+neighbours
+normalisation
+normalise
+normalised
+normalising
+optimisation
+Optimisation
+optimisations
+Optimisations
+optimise
+Optimise
+optimised
+Optimised
+optimising
+Optimising
+organisation
+organise
+organised
+organises
+personalise
+personalised
+podge
+pre
+prepend
+prepended
+prepending
+prioritise
+quantised
+randomise
+randomising
+recognisable
+recognise
+recognised
+reorganise
+reorganised
+serialisation
+serialises
+serialising
+specialisation
+summarised
+summarising
+synchronisation
+synchronise
+synchronised
+synthesised
+uncategorised
+uncategorized
+uninitialised
+unintuitively
+unnormalised
+unnormalized
+unrecognisable
+unrecognise
+unrecognised
+utilise
+utilised
+vectorised
+virtualisation
+virtualised
+visualisation
+visualisations
+visualise
+visualised
+visualiser
+visualising
+Visualising
@@ -0,0 +1,145 @@
+ABI
+accessor
+accessors
+analytics
+Analytics
+AoS
+auditable
+autidable
+autocomplete
+autocompleted
+autocompletion
+autogenerated
+automatable
+backend
+bitfield
+Bitfield
+bitfields
+Bitfields
+bitmask
+bitness
+bitwise
+boolean
+bools
+bugfix
+bugfixes
+bytecode
+byteOffset
+callstack
+callstacks
+checkbox
+checkboxes
+cmake
+codebase
+codebases
+combobox
+config
+dataset
+deallocation
+debuggable
+decompile
+decompiler
+decompiling
+desync
+desyncs
+devkit
+disassemblers
+dockarea
+draggable
+dropdown
+embeddable
+enum
+enumerants
+enums
+executable
+executables
+filesystem
+filetype
+github
+Goto
+groupbox
+hardcoded
+hostname
+ident
+idents
+interop
+iterable
+keybind
+Keybind
+keybinds
+Keybinds
+keycodes
+keypress
+linux
+localhost
+logfile
+lookups
+lossy
+macOS
+monospaced
+multithreaded
+multithreading
+namespace
+namespacing
+NaN
+nullable
+params
+passwordless
+plaintext
+pointee
+posix
+preprocessor
+printf
+printfs
+programmably
+programmatically
+proxied
+proxying
+QWidget
+recurse
+Recursing
+recursively
+refcounted
+refcounting
+runtime
+serialise
+serialised
+snapshotted
+SoA
+spinbox
+stackframe
+stateful
+stderr
+stdout
+stringified
+struct
+structs
+subfolder
+subfolders
+submenus
+substring
+substrings
+textbox
+threadable
+tooltip
+typechecking
+typedef
+typeless
+typename
+ui
+uint
+uints
+uncheck
+unchecking
+unitless
+unix
+unprocessable
+unregister
+Unregister
+Unregisters
+unregistration
+unstripped
+unsuffixed
+untyped
+whitelist
+Zstd
@@ -0,0 +1,123 @@
+api
+arcball
+backface
+baseVertex
+bindless
+bindpoint
+blackpoint
+blit
+blitted
+bresenham
+Broadcom
+capturable
+casted
+cbuffer
+colorise
+colorising
+commandbuffer
+cubemap
+cubemaps
+downsample
+downsampled
+drawcall
+drawcalls
+dxc
+eventid
+eventId
+eventIds
+flycam
+framebuffer
+framecapture
+framerate
+fullscreen
+fxc
+gbuffer
+gbuffers
+GCN
+glsl
+glslang
+grayscale
+hlsl
+lookat
+luma
+meshlet
+meshlets
+minification
+mip
+mips
+multisample
+Multisample
+multisampled
+multisampling
+Multisampling
+multiview
+Nsight
+numInstances
+numViews
+nvidia
+nVidia
+Nvidia
+OpenGL
+patchlist
+Perf
+Profiler
+qrenderdoc
+Qualcomm
+Radeon
+rasterization
+rasterize
+rasterized
+rasterizer
+rasterizing
+raytracing
+rdc
+rects
+renderdoc
+renderers
+renderpass
+Renderpass
+renderpasses
+replayable
+rgp
+RTs
+shader
+shaders
+spirv
+sRGB
+subpass
+subpasses
+subresource
+subresources
+subsampled
+subsampling
+swapchain
+swapchains
+tessellator
+texel
+texels
+unmap
+Unmap
+unmapping
+unproject
+unprojected
+unprojecting
+unprojection
+unprojects
+Verisilicon
+VertexID
+viewport
+viewports
+Vivante
+vsync
+VSync
+vulkan
+wayland
+whitepoint
+wireframe
+Wireframe
+wl
+workgroup
+workgroups
+Xcb
+Xlib
+ycbcr
@@ -18,7 +18,7 @@ The Program section of the dialog prompts for the executable to be launched, the

 .. figure:: ../imgs/Screenshots/CapturePathCmdline.png

-  Program Capture: Configuring and launching an exe directly from RenderDoc.
+  Program Capture: Configuring and launching an executable directly from RenderDoc.

 The :guilabel:`...` buttons next to the executable path and working directory can be used to browse through the file system. If you are working in :doc:`a remote context <../how/how_network_capture_replay>` then the file and directory browser will be replaced by one that browses in the file system of the remote context. By default if the working directory box is left empty then the directory containing the executable will be used as the working directory.

@@ -156,7 +156,7 @@ This option is slightly different from the others in that it doesn't change anyt

 This option allows you to queue up a precise capture of a given frame number after the program has started.

-Queueing up a capture beginning at frame 0 has a special meaning: Frames are defined as the period between two presents of a window. Frame 0 is defined as starting at initialisation and ending at the first presentation.
+Queuing up a capture beginning at frame 0 has a special meaning: Frames are defined as the period between two presents of a window. Frame 0 is defined as starting at initialisation and ending at the first presentation.

 The definition of 'initialisation' varies by API, since it can be hard to clearly define initialisation time cleanly:

@@ -191,17 +191,17 @@ Global Process Hook

 To expose this option you have to enable it in :doc:`the settings <settings_window>`, to prevent it being used accidentally.

-When you've entered a path, or filename, in the executable text at the top of the window, this option will then insert a global hook that causes **every** new process created to load a very small shim dll.
+When you've entered a path, or filename, in the executable text at the top of the window, this option will then insert a global hook that causes **every** new process created to load a very small shim DLL.

-The shim dll will load, create a thread that checks to see if the process matches the path or filename specified, and then unload. If the process matches it will also inject RenderDoc and capturing will continue as normal. At this point you should *first disable the global hook*, then you can use the 'Attach to running instance' menu option to continue as normal.
+The shim DLL will load, create a thread that checks to see if the process matches the path or filename specified, and then unload. If the process matches it will also inject RenderDoc and capturing will continue as normal. At this point you should *first disable the global hook*, then you can use the 'Attach to running instance' menu option to continue as normal.

-RenderDoc implements this behaviour by modifying the `AppInit_DLLs <http://support2.microsoft.com/kb/197571>`_ registry key to reference RenderDoc's dlls. This is not a particularly safe method but it's the only reliable method to do what we want. The shim dll is deliberately made as small and thin as possible, referencing only ``kernel32.dll``, to minimise any risks.
+RenderDoc implements this behaviour by modifying the `AppInit_DLLs <http://support2.microsoft.com/kb/197571>`_ registry key to reference RenderDoc's DLLs. This is not a particularly safe method but it's the only reliable method to do what we want. The shim DLL is deliberately made as small and thin as possible, referencing only ``kernel32.dll``, to minimise any risks.

 .. note::

  If you have 'secure boot' enabled in Windows, the AppInit_DLLs registry key will not work. To use the global process hook you must disable secure boot.

-If RenderDoc crashes or something otherwise goes wrong while these registry keys are modified, the shim dll will continue to be injected into every process which is certainly not desirable. Should anything go wrong, RenderDoc writes a ``.reg`` file that restores the registry to its previous state in ``%TEMP%``.
+If RenderDoc crashes or something otherwise goes wrong while these registry keys are modified, the shim DLL will continue to be injected into every process which is certainly not desirable. Should anything go wrong, RenderDoc writes a ``.reg`` file that restores the registry to its previous state in ``%TEMP%``.

 Again, **this method should be a last resort**. Given the risks you should always try to capture directly in some way before trying this.

@@ -55,7 +55,7 @@ During running or after the application has closed, all captures will appear as

 	Connection Window: Viewing multiple captures taken in a program.

-In this example we have a connection window open to the debugmarker sample from Sascha Willms' Vulkan examples. Three captures have been made and we can see their thumbnails to help distinguish between them. This is visible at any point, regardless of whether you have close the program or not - you can simply switch back to RenderDoc while it's running.
+In this example we have a connection window open to the ``debugmarker`` sample from `Sascha Willems' Vulkan examples <https://github.com/SaschaWillems/Vulkan>`_. Three captures have been made and we can see their thumbnails to help distinguish between them. This is visible at any point, regardless of whether you have close the program or not - you can simply switch back to RenderDoc while it's running.

 .. note::

@@ -116,7 +116,7 @@ The left and right arrows go into and out of hierarchy levels. When within a lev

 .. note::

-	This window supports copy and paste, so simply select the entries and ctrl-c to copy to the clipboard
+	This window supports copy and paste, so simply select the entries and :kbd:`Ctrl-C` to copy to the clipboard

 Bookmarks
 ---------
@@ -79,11 +79,11 @@ To select which element will be displayed as secondary, simply right click on th

 The selection will be remembered as long as the mesh format stays consistent between actions.

-You can also use this if the position data isn't detected in your inputs and you'd like to choose which element contains the positions, or if you'd like to visualise some other data such as UV co-ordinates as positional (in effect rendering the mesh in uv-space).
+You can also use this if the position data isn't detected in your inputs and you'd like to choose which element contains the positions, or if you'd like to visualise some other data such as UV co-ordinates as positional (in effect rendering the mesh in UV-space).

 .. figure:: ../imgs/Screenshots/SolidPreview.png

-	Preview: Previewing the uv co-ordinates as color on the mesh.
+	Preview: Previewing the UV co-ordinates as color on the mesh.

 When displaying the post-projection output - typically the VS output, but possibly tessellation/geometry output - you can select how much data to display.

@@ -253,8 +253,8 @@ Other custom tools can be configured, but for those the command line arguments m
 * ``{input_file}`` will be replaced by the input filename.
 * ``{output_file}`` will be replaced by the output filename.
 * ``{entry_point}`` will be replaced by the entry point name, only when compiling a shader.
-* ``{glsl_stage4}`` will be replaced by the glsl stage short-hand, one of: vert, tesc, tese, geom, frag, or comp.
-* ``{hlsl_stage2}`` will be replaced by the hlsl stage short-hand, one of: vs, hs, ds, gs, ps, or cs.
+* ``{glsl_stage4}`` will be replaced by the glsl stage short-hand, one of: ``vert``, ``tesc``, ``tese``, ``geom``, ``frag``, or ``comp``.
+* ``{hlsl_stage2}`` will be replaced by the hlsl stage short-hand, one of: ``vs``, ``hs``, ``ds``, ``gs``, ``ps``, or ``cs``.
 * ``{spirv_ver}`` will be replaced by the SPIR-V version in use, e.g. spirv1.2 or spirv1.6.
 * ``{vulkan_ver}`` will be replaced by the Vulkan-identified SPIR-V version in use, e.g. vulkan1.0 or vulkan1.3. This value may be lossy, and will pick the next *lowest* version that compiles with a given SPIR-V version. E.g. SPIR-V 1.2 was not used by a vulkan version, so will be rounded down to vulkan1.0.

@@ -344,7 +344,7 @@ These overlays are only relevant when the currently selected action is a rasteri

 * ``Quad Overdraw (Draw)`` will show a similar visualisation to the above option, but limited only to the current drawcall.

-* ``Triangle Size (Pass)`` will show a visualisation of how much pixel area triangles in the meshes are covering in the 'pass' up to the selected draw, up to 4x4 pixels (16 square px) at most. If the current API does not have the concept of a pass, it is defined as all the drawcalls with the same set of render targets.
+* ``Triangle Size (Pass)`` will show a visualisation of how much pixel area triangles in the meshes are covering in the 'pass' up to the selected draw, up to 4x4 pixels (16 square pixels) at most. If the current API does not have the concept of a pass, it is defined as all the drawcalls with the same set of render targets.

 * ``Triangle Size (Draw)`` will show a similar visualisation to the above option, but limited only to the current drawcall.