Web Replay: Allow layout and painting after diverging from recording

RESOLVED FIXED in Firefox 64

Status

()

enhancement
RESOLVED FIXED
9 months ago
7 months ago

People

(Reporter: bhackett, Assigned: bhackett)

Tracking

(Blocks 1 bug)

Trunk
mozilla64
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox64 fixed)

Details

Attachments

(18 attachments, 4 obsolete attachments)

182.62 KB, patch
Details | Diff | Splinter Review
1019 bytes, patch
froydnj
: review+
Details | Diff | Splinter Review
2.39 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
3.61 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
3.00 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
44.57 KB, patch
froydnj
: review+
Details | Diff | Splinter Review
10.33 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
1.92 KB, patch
froydnj
: review+
Details | Diff | Splinter Review
64.91 KB, patch
froydnj
: review+
Details | Diff | Splinter Review
15.40 KB, patch
froydnj
: review+
Details | Diff | Splinter Review
8.36 KB, patch
froydnj
: review+
Details | Diff | Splinter Review
7.34 KB, patch
loganfsmyth
: review+
Details | Diff | Splinter Review
3.12 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
8.89 KB, patch
nical
: review+
Details | Diff | Splinter Review
2.79 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
7.46 KB, patch
mccr8
: review+
Details | Diff | Splinter Review
4.59 KB, patch
froydnj
: review+
Details | Diff | Splinter Review
2.74 KB, patch
nical
: review+
Details | Diff | Splinter Review
Assignee

Description

9 months ago
When deciding how to handle graphics updates when recording or replaying, Web Replay's design goals are pulling it in two opposing directions.  On the one hand, painting takes time, and to get performance that matches with a normal browsing experience we should only be painting as often as that normal browser --- at regular intervals according to the vsyncs received from the UI process.  On the other hand, when someone rewinds to a point of execution they expect to see page graphics that reflect the DOM and other state at that point, and to do this we need to paint as often as possible.

Currently we paint at every turn of the main thread's event loop, provided anything visible has changed.  This is both too often and not often enough.  We could be painting more often than the vsyncs would require us to, and yet, if a page update occurs between turns of the event loop, we won't be able to immediately paint.  The latter part is easily visible in the debugger.  When using the debugger in a normal tab and stepping over a statement that updates the DOM, the result is immediately visible.  When using the debugger in a recording/replaying tab, the update won't become visible until an unpredictable later time.  This is confusing for users, but attempting to paint after every single JS operation that affects the DOM seems untenable for performance (let alone after every other DOM-affecting operation where we could potentially pause in the future).

This dilemma exists because we have to paint at the same points when replaying as we did while recording.  Layout and (in particular) painting calls into the system, and in doing so adds events to the recording that must occur at the same place while replaying.  Now, what if we were able to fix this, and could paint at different places while replaying than we did while recording?  The benefits are extremely appealing:

- While recording, we only have to paint when desired by a vsync.

- While replaying, we can paint wherever we want, and the graphics shown for the tab will always reflect the state of the DOM at any point we are paused at.

- Paints can happen asynchronously.  While the painting already happens on a separate compositor thread, when recording/replaying we currently have to block the main thread to ensure that the paint completes before the next event is processed.  On my computer we spent an average of 8ms or so blocking here on each paint on a sample webpage (scrolling around a large image), which would be 500ms per second if we wanted to paint at 60fps.  I believe this is the main reason for slower performance in a recording/replaying process vs. a normal content process; see also bug 1488086.  With recording-independent paints there is no reason to block the main thread while waiting for paints to complete.

- Background replaying processes never need to paint.  Typically, we spawn three child processes when recording/replaying a page --- one recording child, and two replaying children.  Only one of these processes is active at a time (is able to show graphics which the user will actually see), but with the current design any background replaying processes still have to go through the layout and painting logic as they run through the recording, painting to a buffer of memory which no one will ever see.  With recording-independent paints these background children don't need to do this wasteful effort.

- Reducing the scope of the recording also reduces the size of recording files, though I don't know by how much.

That's the good news.  Actually getting this to work requires striking out into some new territory: handling calls into system libraries that occur differently while replaying than while recording.  We already do this in limited ways, e.g. mmap and mprotect are both redirected but allow calls to happen differently between recording and replaying.  The calls made while painting are more complicated and extensive, but not hugely so.  Thanks mainly to the fact that the Skia graphics backend minimizes its interaction with the system, the main system library calls made --- even while rendering a complex site like Facebook --- are related to font rendering.  Since these calls are mostly pure, I'm hoping it will be sufficient to capture these calls while recording and their results, then while replaying look at incoming calls and match them up with ones made while recording.  If that doesn't work there are other tricks to try, though.
Assignee

Comment 1

9 months ago
Posted patch WIP (obsolete) — Splinter Review
Rough WIP to test the feasibility of the approach.  This patch disallows thread events during layout and painting.  Locking operations in these areas just don't affect the recording, and calls which might occur have extra logic to generate a wrapper object for system objects (CFArrayRef, CGFontRef, etc.) so that we'll be able to track it as it is passed around between calls and match activity up during replay with other activity that happened while recording.  This is mainly testing that (a) there isn't any unexpected behavior/calls during layout and painting which we won't be able to reliably replay, and (b) the system objects used in these parts of the codebase are isolated from those used in other areas and suitable for redirections to generate the wrapper objects.  There weren't any big surprises working on this and things look good for moving forward.  First, though, I want to rework the redirections to make it easier/cleaner to add the wrapper object functionality.
Assignee

Updated

8 months ago
Depends on: 1491067
Assignee

Comment 2

8 months ago
Posted patch WIP (obsolete) — Splinter Review
WIP that is able to paint graphics while replaying at points that were not painted while recording, on a simple page.

Getting here has been difficult and required several rewrites / redesigns.  The main problem is that it isn't simple to separate layout and painting so that they don't affect the rest of the browser's behavior, which we would need in order to make them independent from the recording.  Layout activity in particular can post runnables and trigger other behaviors in the browser that care about when things have been rendered.

To that end, this patch walks back the title of this bug.  Instead of making layout and painting independent from the recording, we will still include these in the recording and perform them when replaying.  This invalidates the 4th and 5th bullets above, though we will be doing fewer paints than currently so replaying time and recording size should both go down somewhat.  In order to do a layout/paint that did not happen while recording, we now simply diverge from the recording and trigger a repaint.  Getting this to actually work requires a couple major changes:

- Library calls which occur after diverging are performed in the middleman process.  Currently, when we encounter a redirected call after diverging, we (with a few exceptions) rewind to a checkpoint created before the divergence and mark the operation which triggered the divergence as having failed.  This doesn't work with layout and painting, which can perform many different library calls and need a mechanism for handling these.  This patch extends the redirections infrastructure so that redirections can specify a hook that handles saving inputs to the call in the replaying process, decoding those inputs in the middleman, then doing the reverse for the call's outputs.

- The compositor thread needs to be able to diverge from the recording itself.  Currently we only allow the main thread to diverge from the recording, and supporting this for a separate thread requires a fair number of changes.

This patch still needs a lot more work to function robustly and tidy up the changes being made.
Attachment #9007667 - Attachment is obsolete: true
Assignee

Updated

8 months ago
Summary: Web Replay: Recording-independent layout and painting → Web Replay: Allow layout and painting after diverging from recording
Assignee

Comment 3

8 months ago
Posted patch WIP (obsolete) — Splinter Review
This is getting pretty close to being done.  I added a stress testing mode where all painting and layout is first done while diverged from the recording, which is able to render e.g. Facebook without failures or glitches.  A little work is still needed: I think some considerable improvements are still possible to how the main thread coordinates with the compositor when diverging from the recording.
Attachment #9011313 - Attachment is obsolete: true
Assignee

Comment 4

8 months ago
Posted patch patch (obsolete) — Splinter Review
Complete patch, still needs rebasing and splitting up for review.
Attachment #9014253 - Attachment is obsolete: true
Assignee

Comment 5

8 months ago
Posted patch patchSplinter Review
Updated rolled up patch, rebased and with a few more improvements.
Attachment #9014884 - Attachment is obsolete: true
Assignee

Comment 6

8 months ago
Fix a couple of existing preamble functions that don't set the call's return value correctly.
Attachment #9015040 - Flags: review?(nfroyd)
Assignee

Comment 7

8 months ago
This reorganizes some of the logic when diverging from the recording in the navigation code, in order to fix a bug where PausedPhase::MaybeDivergeFromRecording does the wrong check to see if the current request had an unhandled recording divergence.
Attachment #9015042 - Flags: review?(continuation)
Assignee

Comment 8

8 months ago
Fix a bug where the IPC channel's message buffer --- whose contents are in untracked memory --- is itself allocated in tracked memory.  If the buffer grows and is reallocated, and we then rewind to a place before that reallocation, the buffer will point to the wrong block of memory.
Attachment #9015044 - Flags: review?(continuation)
Assignee

Comment 9

8 months ago
Change MaybeCreateInitialCheckpoint to CreateCheckpoint to make the function's name match with what it actually does.  This also makes sure we don't create checkpoints after diverging from the recording.
Attachment #9015045 - Flags: review?(continuation)
Assignee

Comment 11

8 months ago
(In reply to Brian Hackett (:bhackett) from comment #10)
> Created attachment 9015046 [details] [diff] [review]
> Part 5 - Add infrastructure for performing system calls in the middleman
> process.

Oops, forgot the comment on this patch:

This allows function redirections to specify a callback that is invoked after diverging from the recording and allows the call to be performed in the middleman process instead.  We can't perform these system calls in the replaying process itself because rewinding can mess up the internal state of the closed source libraries these calls use.  The callback serializes any input data to the call for transmission to the middleman, and serializes any output data produced by the middleman for use in the replaying process.  As with the RR_* callbacks, middleman call callbacks are designed for easy templatization and composition.
Assignee

Comment 12

8 months ago
Add some new IPC to support the middleman calls in part 5.
Attachment #9015047 - Flags: review?(continuation)
Assignee

Comment 13

8 months ago
Keeping track of the PID of the recording process is needed in order to perform getpid() calls after a replaying process diverges from the recording.  Unlike other system calls, this is one we can't just ask the middleman to do on the replaying process' behalf.
Attachment #9015048 - Flags: review?(nfroyd)
Assignee

Comment 14

8 months ago
This patch has all changes to redirections to support performing layout and painting after diverging from the recording.  This adds middleman call callbacks for the system calls (CoreFoundation, CoreGraphics, CoreText, etc.) that can be invoked during layout and by the compositor, mainly for rendering fonts.  It also has fixes for other redirections like getpid and mach_absolute_time so that they can be used after diverging from the recording, and reorganizes the handling of objc_msgSend so that we can watch for certain Objective C messages that can be sent after diverging from the recording and give them specialized handling.
Attachment #9015049 - Flags: review?(nfroyd)
Assignee

Comment 15

8 months ago
In order to paint after diverging from the recording, the compositor thread needs to be able to diverge from the recording itself.  Currently we only allow the main thread to diverge from the recording, and this patch makes some changes so that other threads can be instructed to diverge as well.  Every time a thread interacts with its recording, it enters a RecordingEventSection that ensures that all writes will occur atomically with respect to the recording (when reading we won't hit the end of the event stream somewhere in the middle).  These are also points where the thread can begin diverging from the recording.
Attachment #9015050 - Flags: review?(nfroyd)
Assignee

Comment 16

8 months ago
After the compositor thread diverges from the recording, it is able to block on live system resources --- the WaitableEvent its message pump uses to wait for incoming messages.  This patch uses the existing NotifyUnrecordedWait API to handle this, and modifies it with a flag to keep the main thread from notifying WaitableEvents in threads that have not diverged (doing so will perturb state in that thread and cause a mismatch between recording and replaying).
Attachment #9015051 - Flags: review?(nfroyd)
Assignee

Comment 17

8 months ago
This patch updates the JS ReplayDebugger and associated files so that they trigger a repaint of the current state whenever the debugger pauses and allows the user to inspect the tab.  If the repaint failed due to the layout/painting code making a system call we don't support in the middleman yet (eventually these will get fixed, but they can still happen), a placeholder PAINT FAILURE message is painted on the tab to indicate this to the user.
Attachment #9015052 - Flags: review?(lsmyth)
Assignee

Comment 18

8 months ago
New bindings needed by the JS changes in part 11.
Attachment #9015053 - Flags: review?(continuation)
Assignee

Comment 19

8 months ago
Reorganize the internal painting logic in child processes so that paints occur asynchronously, and add an API to allow diverging from the recording and repainting, as needed by parts 11 and 12.
Attachment #9015054 - Flags: review?(nical.bugzilla)
Assignee

Comment 20

8 months ago
Parent side changes to painting code to report whether there was a painting failure to the JS modified in part 11.
Attachment #9015055 - Flags: review?(continuation)
Assignee

Comment 21

8 months ago
Add a mode (activated by an environment variable) where we diverge from the recording and repaint at the start of every vsync.  This makes sure that all activity that happens in layout/painting also works after diverging from the recording.
Attachment #9015056 - Flags: review?(continuation)
Assignee

Comment 22

8 months ago
One outstanding issue with the approach in this bug (and which predates this bug, though it is a lot more apparent now) is that if a thread which has diverged from the recording (the main thread and compositor thread) tries to take a lock which is held by a thread that has not diverged from the recording (all other threads), then it will deadlock.  Eventually we might need a way to detect these deadlocks and treat them as an unhandled divergence, but for now this patch fixes some of them with special handling to suppress runnable dispatches and IPDL messages that are not necessary for compositing.
Attachment #9015057 - Flags: review?(nfroyd)
Assignee

Comment 23

8 months ago
Rework browser instrumentation so that we perform paints at the normal times according to vsyncs received from the UI process.  We still need some instrumentation for creating checkpoints after each paint, and for notifying the record/replay system about incoming vsyncs (used by the stress testing mode in part 15).
Attachment #9015058 - Flags: review?(nical.bugzilla)
Note for the not-so-distant future: WebRender will probably make it easier for webreplay because rendering is moved out of the content process (some of the tricky things to record won't need to be recorded anymore) and the frequencies at which the display list is built on the content process and rendered in the parent or GPU process are mostly independent (it should give you the possibility of only building the display list during the stable state if layout changed without worrying about vsync, and render normally during vsync).
Attachment #9015058 - Flags: review?(nical.bugzilla) → review+
Attachment #9015054 - Flags: review?(nical.bugzilla) → review+
Attachment #9015040 - Flags: review?(nfroyd) → review+
Attachment #9015046 - Flags: review?(nfroyd) → review+
Comment on attachment 9015048 [details] [diff] [review]
Part 7 - Keep track of the PID of the recording process.

Review of attachment 9015048 [details] [diff] [review]:
-----------------------------------------------------------------

I'm going to assume that something uses this in the next 9 parts...
Attachment #9015048 - Flags: review?(nfroyd) → review+
Attachment #9015042 - Flags: review?(continuation) → review+
Attachment #9015044 - Flags: review?(continuation) → review+
Comment on attachment 9015045 [details] [diff] [review]
Part 4 - Rename MaybeCreateInitialCheckpoint.

Review of attachment 9015045 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/recordreplay/ipc/ChildIPC.h
@@ +28,5 @@
>  // Get the IDs of the middleman and parent processes.
>  base::ProcessId MiddlemanProcessId();
>  base::ProcessId ParentProcessId();
>  
> +// Create a normal checkpoint.

Should this comment indicate that nothing happens if we've diverged? Or is that obvious?
Attachment #9015045 - Flags: review?(continuation) → review+
Comment on attachment 9015047 [details] [diff] [review]
Part 6 - IPC for performing system calls in the middleman.

Review of attachment 9015047 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/recordreplay/ipc/Channel.h
@@ +97,5 @@
>                                                                 \
>    /* Set whether to save a particular checkpoint. */           \
>    _Macro(SetSaveCheckpoint)                                    \
>                                                                 \
> +  /* Respond to a CallRequest message. */                      \

Maybe these Call* messages could be SystemCall* instead? Call is a little generic.

::: toolkit/recordreplay/ipc/ParentIPC.cpp
@@ +1209,5 @@
> +static void
> +RecvCallRequest(const CallRequestMessage& aMsg)
> +{
> +  InfallibleVector<char> outputData;
> +  ProcessMiddlemanCall(aMsg.BinaryData(), aMsg.BinaryDataSize(), &outputData);

I guess this isn't a security problem because the middleman process runs at the same priv level as the child? Something to keep in mind in case that ever changes.
Attachment #9015047 - Flags: review?(continuation) → review+
Attachment #9015053 - Flags: review?(continuation) → review+
Comment on attachment 9015055 [details] [diff] [review]
Part 14 - Parent side graphics changes for repainting.

Review of attachment 9015055 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/recordreplay/ipc/ParentForwarding.cpp
@@ -76,5 @@
>      if (type == dom::PContent::Msg_SetXPCOMProcessAttributes__ID) {
>        // Preferences are initialized via the SetXPCOMProcessAttributes message.
>        PreferencesLoaded();
>      }
> -    if (type == dom::PBrowser::Msg_RenderLayers__ID) {

Why is this being deleted here?
Attachment #9015055 - Flags: review?(continuation) → review+
Comment on attachment 9015056 [details] [diff] [review]
Part 15 - Add repainting stress testing mode.

Review of attachment 9015056 [details] [diff] [review]:
-----------------------------------------------------------------

::: toolkit/recordreplay/ipc/ParentGraphics.cpp
@@ +177,5 @@
>  
> +bool
> +InRepaintStressMode()
> +{
> +  static bool checked = false, rv;

Please declare rv on a separate line.
Attachment #9015056 - Flags: review?(continuation) → review+
Attachment #9015052 - Flags: review?(lsmyth) → review+
Comment on attachment 9015057 [details] [diff] [review]
Part 16 - Avoid deadlocking in a few places after diverging from the recording.

Review of attachment 9015057 [details] [diff] [review]:
-----------------------------------------------------------------

I can believe that this enables things to happen, but large hammers are being used here.  What's the use case for allowing a small number of messages through and stopping all runnables from going anywhere?

::: xpcom/threads/ThreadEventTarget.cpp
@@ +135,5 @@
>    }
>  
> +  // Don't dispatch runnables to other threads when replaying and diverged from
> +  // the recording, to avoid deadlocking with other idle threads.
> +  if (recordreplay::HasDivergedFromRecording()) {

This is a pretty big hammer, since this affects events dispatched to *any* thread from *any* where.  I'm surprised the browser is even functional after this.
Attachment #9015057 - Flags: review?(nfroyd) → review-
Assignee

Comment 31

8 months ago
(In reply to Andrew McCreight [:mccr8] from comment #28)
> Comment on attachment 9015055 [details] [diff] [review]
> Part 14 - Parent side graphics changes for repainting.
> 
> Review of attachment 9015055 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: toolkit/recordreplay/ipc/ParentForwarding.cpp
> @@ -76,5 @@
> >      if (type == dom::PContent::Msg_SetXPCOMProcessAttributes__ID) {
> >        // Preferences are initialized via the SetXPCOMProcessAttributes message.
> >        PreferencesLoaded();
> >      }
> > -    if (type == dom::PBrowser::Msg_RenderLayers__ID) {
> 
> Why is this being deleted here?

This logic isn't necessary anymore, and hasn't been for a while.  We used to generate IPDL messages manually to construct a layer tree to show on each graphical update, and needed this handling to make sure there was a layer tree in place at the times when the UI process expected there to be one.  Now, we render graphics using a canvas in the middleman process, which both eliminates the need to generate our own IPDL messages and eliminates the need for this special case.
Assignee

Comment 32

8 months ago
(In reply to Nathan Froyd [:froydnj] from comment #30)
> Comment on attachment 9015057 [details] [diff] [review]
> Part 16 - Avoid deadlocking in a few places after diverging from the
> recording.
> 
> Review of attachment 9015057 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I can believe that this enables things to happen, but large hammers are
> being used here.  What's the use case for allowing a small number of
> messages through and stopping all runnables from going anywhere?
> 
> ::: xpcom/threads/ThreadEventTarget.cpp
> @@ +135,5 @@
> >    }
> >  
> > +  // Don't dispatch runnables to other threads when replaying and diverged from
> > +  // the recording, to avoid deadlocking with other idle threads.
> > +  if (recordreplay::HasDivergedFromRecording()) {
> 
> This is a pretty big hammer, since this affects events dispatched to *any*
> thread from *any* where.  I'm surprised the browser is even functional after
> this.

When HasDivergedFromRecording() returns true, the browser is paused at a breakpoint or somewhere else and the debugger is interacting with it --- performing eval()s, accessing objects, and (with the changes in this bug) painting the current state.  We don't expect the browser to function after diverging from the recording; if we want to resume the replay we will rewind to a point before we diverged from the recording, and then continue executing from there.  We do need the browser to function enough to perform the actions the debugger needs, though.  The filter for IPDL messages covers those messages that are sent from the main thread to the compositor thread and need to be received by the compositor in order for it to complete the paints which the main thread triggered.

The reason for having a filter at all (and prohibiting inter-thread dispatches) is that when the browser pauses and diverges from the recording, only the main thread (and possibly the compositor thread) actually diverge.  The remaining threads are paused somewhere in the recording and due to lock ordering constraints are unable to make progress until the main thread resumes replaying the recording (which it won't do until after rewinding, because it has diverged from the recording).  Those other threads could be holding locks, however, and if the main thread or compositor thread tries to take one of those locks, they will deadlock.  The checks in this patch fix the places where I have seen such deadlocks, but there are probably others.

There are other ways to deal with this, but for the moment all will require browser instrumentation.  It would be nice to be able to eliminate this patch entirely, and it might be possible to do so in the future, but we would need a way to guarantee the main and compositor threads can't deadlock with an idle thread, and figuring out how to do that will require some studying.
Assignee

Updated

7 months ago
Depends on: 1499186
Comment on attachment 9015057 [details] [diff] [review]
Part 16 - Avoid deadlocking in a few places after diverging from the recording.

Review of attachment 9015057 [details] [diff] [review]:
-----------------------------------------------------------------

bhackett has helped me understand that this is actually reasonable.

::: xpcom/threads/ThreadEventTarget.cpp
@@ +135,5 @@
>    }
>  
> +  // Don't dispatch runnables to other threads when replaying and diverged from
> +  // the recording, to avoid deadlocking with other idle threads.
> +  if (recordreplay::HasDivergedFromRecording()) {

Please put in some kind of explanatory comment here to help the next person that comes along and goes "huh?  completely stopping the event loop can't be good".
Attachment #9015057 - Flags: review- → review+
Comment on attachment 9015049 [details] [diff] [review]
Part 8 - Redirection changes for supporting layout and painting after diverging from the recording.

Review of attachment 9015049 [details] [diff] [review]:
-----------------------------------------------------------------

The amount of things that need to be caught here is rapidly approaching the "terrifying" level.
Attachment #9015049 - Flags: review?(nfroyd) → review+
Attachment #9015050 - Flags: review?(nfroyd) → review+
Attachment #9015051 - Flags: review?(nfroyd) → review+

Comment 35

7 months ago
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/42143e96a1ea
Part 1 - Fix return value sets in Preamble_Veto, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/33cf80c72148
Part 2 - Fix checks after an unhandled divergence in the first debugger request after pausing, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9e7dfd8ce93
Part 3 - Store channel buffer's containing vector in untracked memory, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/4dd9ee253d32
Part 4 - Rename MaybeCreateInitialCheckpoint, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/4478e865d770
Part 5 - Add infrastructure for performing system calls in the middleman process, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/5b5ae360b887
Part 6 - IPC for performing system calls in the middleman, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b6ca168b7e52
Part 7 - Keep track of the PID of the recording process, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0130de663e9f
Part 8 - Redirection changes for supporting layout and painting after diverging from the recording, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0ce807f9d1f6
Part 9 - Specify regions of code where recording is not interrupted and threads can diverge, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/baaaaa544bb0
Part 10 - Notify the record/replay system when a message pump thread blocks after diverging from the recording, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/597cf7ce986a
Part 11 - JS changes to trigger repaints after diverging from the recording, and handle the response, r=lsmyth.
https://hg.mozilla.org/integration/mozilla-inbound/rev/2ba7db69225b
Part 12 - Bindings for JS repainting logic, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9b5b68080ee6
Part 13 - Avoid blocking the main thread when painting, and allow repaints after diverging from the recording, r=nical.
https://hg.mozilla.org/integration/mozilla-inbound/rev/ed0463d80c34
Part 14 - Parent side graphics changes for repainting, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/0fa982d6f06a
Part 15 - Add repainting stress testing mode, r=mccr8.
https://hg.mozilla.org/integration/mozilla-inbound/rev/09a979b6e583
Part 16 - Avoid deadlocking in a few places after diverging from the recording, r=froydnj.
https://hg.mozilla.org/integration/mozilla-inbound/rev/7f2e0b3603b4
Part 17 - Allow paints to happen at the normal time when recording/replaying, r=nical.
Assignee

Updated

7 months ago
Depends on: 1500690
Assignee

Updated

7 months ago
Depends on: 1500805
Assignee

Updated

7 months ago
Depends on: 1503639
You need to log in before you can comment on or make changes to this bug.