Correct spelling/grammar mistakes in docs

2026-05-04 09:00:44 +00:00 · 2018-05-08 14:09:27 +01:00
parent 2efce90591
commit 1a9e22e2f2
18 changed files with 32 additions and 33 deletions
@@ -10,7 +10,7 @@ D3D12 is intended as to have low CPU overhead and be fully threadable, and Rende

 Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of resources. If you do have persistent maps, ensure that either the memory allocation is small or that you have only a few queue submits during the frame - since RenderDoc must compare the whole allocation at every submit to determine what might have changed and save out the delta.

-Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of MBs can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees.
+Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of megabytes can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees.

 Current support
 ---------------
@@ -13,7 +13,6 @@ Planned features
 * Debugging of all shader stages.
 * HLSL Debugging.
 * Mesh display after hull shader stage.
-* Perfkit/PerfHUD integration for vendor-specific detailed performance timers.
 * Diffing events in a given frame.
 * Modifying the pipeline on the fly to change state.
 * Highlighting redundant state-setting.
@@ -26,7 +26,7 @@ Vulkan is intended as a high-performance low CPU overhead API, and RenderDoc str

 Some patterns of access are more or less conducive to good performance on RenderDoc, so if you are having trouble with slow capture, large memory/disk overhead or slow replay you might want to try eliminating use of persistent maps of memory from coherent heaps - you can use ``vkFlushMappedMemoryRanges`` to emulate non-coherent heaps and RenderDoc will take advantage of that, or you can use non-persistent maps.

-Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or mor copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of MBs can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees.
+Likewise try to avoid making very large memory allocations in the range of 1GB and above. By its nature RenderDoc must save one or more copies of memory allocations to enable proper capture, so having allocations limited to only a few 100s of megabytes can help gain granularity of management and limit the memory overhead RenderDoc adds. There may be optimisation of this in future on RenderDoc's side but there are no easy guarantees.

 Current support
 ---------------
@@ -10,7 +10,7 @@ RenderDoc has some very light anonymous analytics to allow analysis of which fea

 The complete details of the analytics can be found in the page about :doc:`../behind_scenes/analytics`, but the brief outline is that RenderDoc records data **only in the replay program** and does not record any data that is specific to any captured programs. The data recorded is primarily boolean flags indicating whether or not a given feature, API, or platform is used or not. You can see the precise list of data gathered on your current RenderDoc build in the settings menu under the :guilabel:`Anonymous Analytics` section.

-The analytics data is summarised and transmitted securely and anonymously to RenderDoc's server. The aggeregated statistics are available for anyone to see at `the analytics homepage <https://renderdoc.org/analytics>`_.
+The analytics data is summarised and transmitted securely and anonymously to RenderDoc's server. The aggregated statistics are available for anyone to see at `the analytics homepage <https://renderdoc.org/analytics>`_.

 Enabling the analytics is greatly appreciated, if you have any concerns about the data gathered you can choose to manually verify each report before it's submitted.

@@ -62,7 +62,7 @@ Currently RenderDoc supports Vulkan 1.0, D3D11 (up to D3D11.3), D3D12, OpenGL 3.

 Vulkan support has :doc:`a few notes <../behind_scenes/vulkan_support>`, as does :doc:`D3D12 <../behind_scenes/d3d12_support>`.

-Future API support is at this point not clear; Metal, WebGL, and perhaps D3D9/D3D10 all being possible. Support for new APIs will be balanced against all other work such as features for existing APIs, bugfixes. So if you care strongly about support for a new API make sure to `file an issue on github <https://github.com/baldurk/renderdoc/issues>`_ or comment on an existing issue to register your interest.
+Future API support is at this point not clear; Metal, WebGL, and perhaps D3D9/D3D10 all being possible. Support for new APIs will be balanced against all other work such as features for existing APIs, bugfixes. So if you care strongly about support for a new API make sure to `file an issue on GitHub <https://github.com/baldurk/renderdoc/issues>`_ or comment on an existing issue to register your interest.

 How can I backup or restore my settings?
 ----------------------------------------
@@ -80,7 +80,7 @@ RenderDoc doesn't install any registry keys on windows aside from those required
 Which network ports does RenderDoc use?
 ---------------------------------------

-RenderDoc uses TCP and UDP ports ``38920-38927`` consecutively for remote access and control (ie. capturing remotely) for each new program that is opened on a machine. Note that even if you initiate a capture locally these ports are still opened for listening. These are the ports that are probed on a remote host to see if a connection exists.
+RenderDoc uses TCP and UDP ports ``38920-38927`` consecutively for remote access and control (i.e. capturing remotely) for each new program that is opened on a machine. Note that even if you initiate a capture locally these ports are still opened for listening. These are the ports that are probed on a remote host to see if a connection exists.

 RenderDoc also uses TCP and UDP ports ``39920`` for remote replay connections, for when a remote host is used to replay and analyse the capture.

@@ -123,9 +123,9 @@ For texture formats that explicitly specify that they contain sRGB data this isn

 For other textures it's more difficult - for starters they may actually contain sRGB data but the correction is handled by shaders so there's no markup. Or indeed the application may not be gamma-correct so the data is sRGB but uncorrected. If we display these textures in a technically correct way, such that the data is not over or under gamma-corrected, the result often looks 'wrong' or unintuitively different from expected.

-Nothing is actually wrong here except perhaps that when visualising linear data it is often more convenient to "overcorrect" 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).
+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 overcorrection 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
 --------------------------------------------------------------------------
@@ -60,7 +60,7 @@ Current Common Feature set
 * Python scripting console with full documented API, giving complete access to RenderDoc internals, core data structures, and the Qt UI itself.
 * Import and Export of captures

-    * Captures have an internal in-memory representation containing the full serialised data of all function calls, as well as associated metadat.
+    * Captures have an internal in-memory representation containing the full serialised data of all function calls, as well as associated metadata.
    * This capture representation can be used to export an ``.rdc`` file to another form that's easier for external tools to work with such as ``.xml``.
    * If the external format contains full expression of data, it can then be imported again back into an ``.rdc`` after modification.
    * This also allows generation of RenderDoc captures from arbitrary data into a standard format.
@@ -95,7 +95,7 @@ OpenGL & OpenGL ES
 * Support for OpenGL ES 2.0 - 3.2 on Linux and Android.
 * Tree hierarchy of events defined by any of the standard or vendor-specific extensions, and ``KHR_debug`` object labels used for object naming.

-Captures have a very limited amount of portability between machines. Many hardware-specific feature uses are baked into captures, and portability depends on how similar the captuer and replay hardware are, whether these feature uses can map the same in both cases. Captures are however completely portable between different OSes with sufficiently comparable hardware.
+Captures have a very limited amount of portability between machines. Many hardware-specific feature uses are baked into captures, and portability depends on how similar the capture and replay hardware are, whether these feature uses can map the same in both cases. Captures are however completely portable between different OSes with sufficiently comparable hardware.

 See Also
 --------
@@ -12,7 +12,7 @@ Things to Note

 * RenderDoc doesn't serialise out the initial contents of large graphics resources when it believes that they will not be used in replay. e.g. a G-Buffer render target will not be saved out as it is initialised and written to in-frame. This detection will go wrong if a render target is partially written to but partially re-used, as RenderDoc will count this as initialised in-frame. This could happen e.g. with an accumulating texture that is written to in the frame over the top of previous results.

-  You can override this behaviour by selecting 'Save All Initials' in the :doc:`capture options <../how/how_capture_frame>` before capturing, as this will force RenderDoc to serialise out all initial contents regardless, at the cost of larger logfiles and slightly slower replay app analysis.
+  You can override this behaviour by selecting 'Save All Initials' in the :doc:`capture options <../how/how_capture_frame>` before capturing, as this will force RenderDoc to serialise out all initial contents regardless, at the cost of larger capture files and slightly slower replay app analysis.

 * When capturing, only one swapchain is captured at any given time. The in-app overlay renders to all swapchains but only one is considered "active" at any given time - this can be cycled with the F11 key. The capture key will trigger a capture at the next swap of the currently active swapchain.

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

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

@@ -37,7 +37,7 @@ When ready, press the Capture Key (:kbd:`F12` or :kbd:`Print Screen`) and the ne

    The in-application RenderDoc Overlay

-When the application exits, if you captured a frame it will automatically start to open in the RenderDoc UI. If you didn't capture a frame then nothing will happen and the RenderDoc UI will be back as it was when you clicked Lanuch.
+When the application exits, if you captured a frame it will automatically start to open in the RenderDoc UI. If you didn't capture a frame then nothing will happen and the RenderDoc UI will be back as it was when you clicked Launch.


 If you made multiple captures you will see a thumbnail list that allows you to open (in the current instance or a new instance to compare side-by-side), save and delete them as you wish. You can also access this view while the program is still running, see :doc:`../window/capture_connection` for more information on taking multiple frame captures. Note however that for the simple use-case, you don't need to worry about this!
@@ -139,7 +139,7 @@ The timeline bar is essentially an alternate view of the frame, with the horizon

 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 drawcall is rendered as a blue pip underneath the section of the hierarchy that it is a child of. The current drawcall (if visible) is rendered as a green circle.

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

 When the currently selected texture is used in the frame, each drawcall that references it draws a marker below the bar. A purple marker indicates that the drawcall at that point is writing to the texture, and a green marker indicates that it is reading. If the markers are too close together they will space themselves to be readable and will not necessarily line up to a particular drawcall unless you zoom in.

@@ -3,7 +3,7 @@ How do I use RenderDoc on Android?

 RenderDoc contains support for Android for both Vulkan and OpenGL ES. It requires a couple of extra steps more than capturing on a desktop computer, but generally the workflow is very similar.

-Android support is still quite new, so if you run into any rough spots please `open an issue on github <https://github.com/baldurk/renderdoc/issues/new>`_ or `email me <mailto:baldurk@baldurk.org?subject=RenderDoc%20on%20Android>`_.
+Android support is still quite new, so if you run into any rough spots please `open an issue on GitHub <https://github.com/baldurk/renderdoc/issues/new>`_ or `email me <mailto:baldurk@baldurk.org?subject=RenderDoc%20on%20Android>`_.

 .. caution::

@@ -56,6 +56,6 @@ If you have Android Studio open, it will interfere with RenderDoc's debugging by

 RenderDoc does its best to locate or provide necessary android tools. 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 variables set, you can browse to the SDK and JDK folders in the :doc:`settings window <../window/settings_window>` under the :guilabel:`Android` section.

-If something goes wrong with these steps, please `open an issue on github <https://github.com/baldurk/renderdoc/issues/new>`__! The process should be as smooth as possible given Android's platform limitations, so if you encounter problems then it may well be fixable.
+If something goes wrong with these steps, please `open an issue on GitHub <https://github.com/baldurk/renderdoc/issues/new>`__! The process should be as smooth as possible given Android's platform limitations, so if you encounter problems then it may well be fixable.

 Often when an operation fails, more information is available via :guilabel:`Help` → :guilabel:`View Diagnostic Log`.
@@ -54,7 +54,7 @@ Pixel History

 When you have a pixel selected, you can click 'History' to open up a pixel history view showing every modification to the selected texture from the start of the frame to the currently selected event.

-This display shows each modifying event as its own row, colored as to whether any modifications happened from this event or not - green for fragments that passed all pipeline tests, red for where fragments failed some test, and light grey for arbitrary shader writable resources where it's unknown if there was a write.
+This display shows each modifying event as its own row, colored as to whether any modifications happened from this event or not - green for fragments that passed all pipeline tests, red for where fragments failed some test, and light gray for arbitrary shader writable resources where it's unknown if there was a write.

 You can expand each event to see if there were multiple fragments, and see the shader output value from each fragment.

@@ -318,7 +318,7 @@ The other way is a closer integration, where your code will explicitly load Rend
    It is advised to call this function twice - first to obtain ``pathlength`` so that sufficient space can be allocated. Then again to actually retrieve the path.


-The path follows the template set in :cpp:func:`SetLogFilePathTemplate` so it may not be an absolute path.
+The path follows the template set in :cpp:func:`SetCaptureFilePathTemplate` so it may not be an absolute path.

 .. cpp:function:: void TriggerCapture()

@@ -49,7 +49,7 @@ In the 3D Mesh preview, you have the option to display the mesh with some solid
 * Flat Shaded will perform basic flat lighting calculations based on triangle normals to give a better idea of the topology of the mesh.
 * Secondary will display the selected secondary mesh element.

-To select which element will be displayed as secondary, simply right click on the column you would like to use. This can be done on the input and output separately, and 4-component columns have the option to either show RGB as color, or alpha as greyscale.
+To select which element will be displayed as secondary, simply right click on the column you would like to use. This can be done on the input and output separately, and 4-component columns have the option to either show RGB as color, or alpha as grayscale.

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

@@ -65,7 +65,7 @@ The dropdown above the mesh view will let you choose to show :guilabel:`this dra

 These let you narrow or expand the mesh outputs displayed. At minimum you will see the current draw - a specific instance, if the drawcall is an instanced draw. You can also display other instances in the same drawcall (either up to the selected instance, or all instances before or after the selected instance). Finally you can opt to display all other meshes up to the current draw in the same notional render pass.

-The current draw is always dark tinted, instances within the same draw have a lighter red color, and other drawcalls in the pass will be light grey.
+The current draw is always dark tinted, instances within the same draw have a lighter red color, and other drawcalls in the pass will be light gray.

 Raw Buffer Viewer
 -----------------
@@ -95,7 +95,7 @@ This option modifies the above capturing of callstacks to only be saved for draw

  | :guilabel:`Enable API validation` Default: ``Disabled``

-Enable API validation causes RenderDoc to enable the API's built-in debugging, and where possible serialise this out and include it in the logfile for later inspection in the :doc:`debug_messages` window.
+Enable API validation causes RenderDoc to enable the API's built-in debugging, and where possible serialise this out and include it in the capture for later inspection in the :doc:`debug_messages` window.

 * On D3D11 & D3D12 this will activate the D3D debug layer and save out any messages.
 * For OpenGL this means ``ARB_debug_output`` is automatically enabled.
@@ -116,7 +116,7 @@ This option causes RenderDoc to hook into process creation calls from the target

  | :guilabel:`Save All Initials` Default: ``Disabled``

-RenderDoc will attempt to save overhead and particularly capture filesize by omitting the initial contents of 2D textures that it believes will be unnecessary. Typically these textures are render targets or depth buffers that will be written to and fully covered in the course of the frame before they are ever read, and so saving their initial contents is unnecessary.
+RenderDoc will attempt to save overhead and particularly capture file size by omitting the initial contents of 2D textures that it believes will be unnecessary. Typically these textures are render targets or depth buffers that will be written to and fully covered in the course of the frame before they are ever read, and so saving their initial contents is unnecessary.

 In some cases this detection will be wrong, such as targets that are partially written such as pools, or if a target is accumulated to via blend modes. When this is the case, enabling Save All Initials will force RenderDoc to save these textures regardless of any auto-detection.

@@ -124,7 +124,7 @@ In some cases this detection will be wrong, such as targets that are partially w

  | :guilabel:`Ref All Resources` Default: ``Disabled``

-One method RenderDoc uses to keep logfile sizes down is to only include the referenced dependencies of a frame within a capture. This means that even if 100 textures are allocated and present, if 50 of them are never bound to the pipeline or otherwise referenced then they will not be included in the logfile. Enabling this option will cause RenderDoc to include all live resources at the time of capture regardless of whether they are used or not.
+One method RenderDoc uses to keep capture file sizes down is to only include the referenced dependencies of a frame within a capture. This means that even if 100 textures are allocated and present, if 50 of them are never bound to the pipeline or otherwise referenced then they will not be included in the capture file. Enabling this option will cause RenderDoc to include all live resources at the time of capture regardless of whether they are used or not.

 ----------

@@ -191,7 +191,7 @@ RenderDoc implements this behaviour by modifying the `AppInit_DLLs <http://suppo

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

@@ -47,7 +47,7 @@ Next you can queue a capture at a specific frame number, if you know that a bug

 .. note::

-	Note, capturing a frame in RenderDoc will cause a noticable stall on any non-trivial application, so if you are investigating a timing issue often this can throw things off and hide the bug. However capturing multiple frames can be useful when you know a bug alternates every N frames, or you specifically want to debug how N sequential frames look and you know extreme frame times won't skew the results.
+   Capturing a frame in RenderDoc will cause a noticeable stall on any non-trivial application, so if you are investigating a timing issue often this can throw things off and hide the bug. However capturing multiple frames can be useful when you know a bug alternates every N frames, or you specifically want to debug how N sequential frames look and you know extreme frame times won't skew the results.

 During running or after the application has closed, all captures will appear as thumbnails here. As mentioned above, if only one capture is made and the application is closed the capture dialog will automatically begin to load it up in the UI. Otherwise you can use this window to browse the captures, save and delete any frame captures, and open them either in the currently running UI or in a new separate instance.

@@ -33,4 +33,4 @@ By default the table is sorted by EID, but each column is sortable individually

 .. |save| image:: ../imgs/icons/save.png

-Clicking the |save| button lets you save the results of the counters as csv.
+Clicking the |save| button lets you save the results of the counters as CSV.
@@ -10,7 +10,7 @@ At the top of the Pipeline Viewer is the pipeline flowchart - this shows the hig

 Each block is a separate page which contains the relevant state and contents for that piece of the graphics pipeline, with specific details varying by API and the type of data to be displayed.

-The currently selected block is outlined with red, and the page in view reflects the contents of that section of the pipeline. Light grey parts of the pipeline are those which are currently active and participating in this drawcall. Dark grey parts of the pipeline are not enabled and can be considered pass-through/do-nothing.
+The currently selected block is outlined with red, and the page in view reflects the contents of that section of the pipeline. Light gray parts of the pipeline are those which are currently active and participating in this drawcall. Dark gray parts of the pipeline are not enabled and can be considered pass-through/do-nothing.

 .. figure:: ../imgs/Screenshots/PipelineBar.png

@@ -183,7 +183,7 @@ This option tries to make the disassembly of shaders easier to read by substitut

 Here you can configure external tools that disassemble binary SPIR-V into a human-readable representation.

-Some built-in tools are supported such as SPIRV-Cross and spirv-dis, for these tools if they can be autodetected they will already be present, and they may be distributed with RenderDoc builds in case a version isn't installed on the system.
+Some built-in tools are supported such as SPIRV-Cross and spirv-dis, for these tools if they can be auto-detected they will already be present, and they may be distributed with RenderDoc builds in case a version isn't installed on the system.

 Other custom tools can be configured, but for those the command line arguments must be configured. The command line arguments will have ``{spv_bin}`` replaced with the full path to the binary SPIR-V file, and ``{spv_disasm}`` with the path of where the human-readable output must be written to.

@@ -280,6 +280,6 @@ This setting, if present, will override all other search paths and be looked in

  | :guilabel:`Max Connection Timeout` Default: ``30 seconds``

-Some Android programs take a long time to start up before they begin renderding. This setting allows you to define a timeout before RenderDoc will consider the execution and connection to have failed.
+Some Android programs take a long time to start up before they begin rendering. This setting allows you to define a timeout before RenderDoc will consider the execution and connection to have failed.

 This only applies to running Android programs.
@@ -112,7 +112,7 @@ There are four other buttons available for control of the range:

 * |wand| **Autofit** - This button automatically fits the range control to the min and max values in any visible channels in the texture. Oftentimes this is a good starting point for a range, although with some extreme textures it may adjust badly.

-  Right clicking on this button will cause it to always auto-fit until you disable this. ie. when you move to another event or another texture, the range will be auto-fit again. This is useful if jumping between events or textures where the visible ranges are very different.
+  Right clicking on this button will cause it to always auto-fit until you disable this. i.e. when you move to another event or another texture, the range will be auto-fit again. This is useful if jumping between events or textures where the visible ranges are very different.

 * |arrow_undo| **Reset** - Simply resets the range back to the default of [0, 1] - useful for resetting after changing to a new texture where the range settings aren't applicable.

@@ -173,7 +173,7 @@ Gamma display of Linear Data

  | γ Gamma display

-A proper explanation of this is available in the :ref:`FAQ <gamma-linear-display>`. In short, linear data is 'overcorrected' to look as expected, but this behaviour can be overridden by toggling off this option.
+A proper explanation of this is available in the :ref:`FAQ <gamma-linear-display>`. In short, linear data is 'over-corrected' to look as expected, but this behaviour can be overridden by toggling off this option.

 Alpha background
 ~~~~~~~~~~~~~~~~
@@ -21,7 +21,7 @@ Timeline Display

 By default the timeline bar views the whole frame, but with the mouse wheel you can zoom in and out. When zoomed in, you can scroll through the frame with the horizontal scroll bar.

-Underneath expanded sections, a blue pip is rendered for each drawcall-type event. The currently selected event is shown as a green pip, as well as there being a light grey vertical line to indicate the current position, such that this is visible even when the relevant section is not expanded.
+Underneath expanded sections, a blue pip is rendered for each drawcall-type event. The currently selected event is shown as a green pip, as well as there being a light gray vertical line to indicate the current position, such that this is visible even when the relevant section is not expanded.

 Clicking on any section will toggle it between expanded and unexpanded, and any sections underneath a section which is collapsed will remain in their previous state but will not be visible.

@@ -45,7 +45,7 @@ A colored triangle will be drawn under each pip that reads from the texture. If
 Pixel history event Display
 ---------------------------

-When a pixel history window is focussed, the timeline bar will show the results over each EID with a red triangle to show rejected pixels and green triangles to show passed pixels.
+When a pixel history window is focused, the timeline bar will show the results over each EID with a red triangle to show rejected pixels and green triangles to show passed pixels.

 .. figure:: ../imgs/Screenshots/PixelHistoryTimeline.png