Descriptionaura: Fix raciness in context loss and recreation.
When the context is lost, we post a task to notify observers about
the loss. They should be able to use the old context to clean up
after themselves. However, if anyone came and asked for the shared
context in between the post task and it executing, the shared context
would be destroyed immediately since we looked in the getter if
the context was lost.
Instead, always return the same context3d from the shared context
getter, and only destroy it in the execution of the post task.
Also, the OwnedTexture class holds a raw pointer to the shared
context, but the OwnedTexture is not destroyed by the lost
context notifications (contrary to a misleading comment). So
when the context is lost, the OwnedTexture needs to drop its
raw pointer to the old context 3d, which will be deleted after
the notification. This ended up incorporating exactly the changes
made by cpu@ in https://codereview.chromium.org/23364002/.
Finally, the compositor thread shared context does not have a lost
context listener in the GpuProcessContextFactory, but we want it to
always be in the same share group as the main thread context. So
when we lost the main thread context and drop the reference on the
context3d, we will also do the same for the compositor thread's
context. This way both contexts are replaced on the main thread at
the same time. The next commit by the compositor will use a new
context for both threads, and a commit between the loss and the
post task executing will use the old contexts on both threads.
R=piman
BUG=275775
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=219119
Patch Set 1 #
Total comments: 2
Patch Set 2 : contextrace: -c #
Messages
Total messages: 5 (0 generated)
|