Bug 1560149 - Followup to fix some typos. r=me
authorKartikaya Gupta <kgupta@mozilla.com>
Wed, 03 Jul 2019 13:55:19 -0400
changeset 544094 edd9db03dc12dfe51c2090b731b102e71b97f0df
parent 544093 e7a49ec024238c80fe2b8764c829b271d3a9e38a
child 544095 f859e4de00079fca494cbee9ee339e3c006215bb
push id2131
push userffxbld-merge
push dateMon, 26 Aug 2019 18:30:20 +0000
treeherdermozilla-release@b19ffb3ca153 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersme
bugs1560149
milestone69.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Bug 1560149 - Followup to fix some typos. r=me
gfx/docs/DocumentSplitting.rst
--- a/gfx/docs/DocumentSplitting.rst
+++ b/gfx/docs/DocumentSplitting.rst
@@ -118,29 +118,29 @@ are also in the UI process. Consider thi
       - display item P
         - display item A
         - display item B (flagged as being in the content renderroot)
         - display item C
 
 If item P was a filter, for example, that would normally apply to all of items
 A, B, and C. This would mean either sharing the filter between the "chrome" renderroot
 and the "content" renderroot, or duplicating it such that it existed in both
-renderroots. The sharing is not possibly as it violates the independence of WR
+renderroots. The sharing is not possible as it violates the independence of WR
 documents. The duplication is technically possible, but could result in visual
 glitches as the two documents would be processed and composited separately.
 
 In order to avoid this problem, the design of document splitting explicitly assumes
 that such a scenario will not happen. In particular, the only information that
 gets carried across the render root boundary is the positioning offset. Any
 filters, transforms that are not 2D axis-aligned, opacity, or mix blend mode
 properties do NOT get carried across the render root boundary. Similarly, a
 scrollframe may not contain content from multiple render roots, because that
 would lead to a similar problem in APZ where it would have to update the scroll
 position of scrollframes in multiple documents and they might get composited
-at separate times resulting in visual glitches.
+at separate times, resulting in visual glitches.
 
 Security Concerns
 -----------------
 
 On the content side, all of the document splitting work happens in the UI process.
 In other words, content processes don't generally know what document they are part
 of, and don't ever split their display lists into multiple documents. Only the UI
 process ever sends multiple display lists to the compositor side.
@@ -220,17 +220,17 @@ corresponding queue. The catch is that o
 element or scrollframe on the page, and so when the message is sent from the
 UI process, we need to do a DOM or frame tree walk to determine which render root
 that element is associated with. There are some `GetRenderRootForXXX
 <https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/gfx/thebes/gfxUtils.h#317-322>`_
 helpers in gfxUtils that assist with this task.
 
 The other catch is that an APZ message may be associated with multiple documents.
 A concrete example is if a user on a touch device does a multitouch action with
-one fingers landing on different documents, which would trigger a call to
+different fingers landing on different documents, which would trigger a call to
 `RecvSetTargetAPZC
 <https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/gfx/layers/ipc/APZCTreeManagerParent.cpp#76>`_
 with multiple targets, each potentially belonging to a different render root.
 In this case, we need to ensure that the message only gets processed after
 the corresponding scene swaps for all the related documents. This is currently
 implemented by having each message in the queue associated with a set of documents
 rather than a single document, and only processing the message once all the
 documents have done their scene swap. In the example above, this is indicated by
@@ -238,29 +238,29 @@ building the set of render roots `here
 <https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/gfx/layers/ipc/APZCTreeManagerParent.cpp#83>`_
 and passing that to the updater queue when queueing the message. This interaction
 is a source of some complexity and may have latent bugs.
 
 Deferred updates
 ~~~~~~~~~~~~~~~~
 
 Bug 1547351 provided a new and tricky problem where a content process is rendering
-stuff that needs go into the "default" document because it's actually an
+stuff that needs to go into the "default" document because it's actually an
 out-of-process addon content that renders in the chrome area. Prior to this bug,
 the WebRenderBridgeParent instances that corresponded to content processes
 (hereafter referred to as "sub-WRBPs", in contrast to the "root WRBP" that
 corresponds to the UI process) simply assumed they were in the "Content" document,
 but this bug proved that this simplistic assumption does not always hold.
 
 The solution chosen to this problem was to have the root WebRenderLayerManager
 (that lives in the trusted UI process) to annotate each out-of-process subpipeline
 with the render root it belongs in, and send that information over to the
 root WRBP as part of the display list transaction. The sub-WRBPs know their own
 pipeline ids, and therefore can find their render root by querying the root WRBP.
-The catch is that sub-WRBPs may receive display list transactions before the
+The catch is that sub-WRBPs may receive display list transactions *before* the
 root WRBP receives the display list update that contains the render root mapping
 information. This happens in cases like during tab switch preload, where the
 user mouses over a background tab, and we pre-render it (i.e. compute and send
 the display list for that tab to the compositor) so that the tab switch is faster.
 In this scenario, that display list/subpipeline is not actually rendered, is not
 tied in to the display list of the UI process, and therefore doesn't get associated
 with a render root.
 
@@ -305,28 +305,28 @@ With document splitting, a transaction s
 and sent to multiple WR documents, each of which are operating independently of
 each other. If we propagate the transaction id to each of those WR documents,
 then the first document to complete its work would trigger the "transaction complete"
 message back to the content, which would unthrottle the next transaction. In this
 scenario, other documents may still be backlogged, so the unthrottling is
 undesirable.
 
 Instead, what we want is for all documents processing a particular transaction
-id to finish their word and render before we send the completion message back
+id to finish their work and render before we send the completion message back
 to content. In fact, there's a bunch of work that falls into the same category
 as this completion message - stuff that should happen after all the WR documents
 are done processing their pieces of the split transaction.
 
 The way this is managed is via a conditional in `HandleFrame
 <https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/gfx/webrender_bindings/RenderThread.cpp#988>`_.
 This code is invoked once for each document as it advances to the rendering step,
 and the code in `RenderThread::IncRenderingFrameCount
 <https://searchfox.org/mozilla-central/rev/06bd14ced96f25ff1dbd5352cb985fc0fa12a64e/gfx/webrender_bindings/RenderThread.cpp#552-553>`_
 acts as a barrier to ensure that the call chain only gets propagated once all
 the documents have done their processing work.
 
 I'm listing this piece as a potential source of complexity for document splitting
-because it seems like a fairly important piece but the relevant code that is
-"buried" away in place where one might not easily stumble upon it. It's also not
+because it seems like a fairly important piece but the relevant code is
+"buried" away in a place where one might not easily stumble upon it. It's also not
 clear to me that the implications of this problem and solution have been fully
 explored. In particular, I assume that there are latent bugs here because other
 pieces of code were assuming a certain behaviour from the pre-document-splitting
 code that the post-document-splitting code may not satisfy exactly.