Resolve issue with flush-time opsTask management
Despite what the bug says, I believe the only issue here was that
all the flush-time opsTasks weren't guaranteed to be in
'fOnFlushRenderTasks'. Since the users of flush-time opsTasks
use GrRenderTargetContext::addDrawOp, if the opsTask were to be
split, new ops would be added to the correct/new opsTask.
Bug: skia:9357
Change-Id: I90577bcc852419a9e0c31d858f71cda9f6f6b6a3
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/336435
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Reviewed-by: Adlai Holler <adlai@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
diff --git a/src/gpu/GrOnFlushResourceProvider.cpp b/src/gpu/GrOnFlushResourceProvider.cpp
index 4ac8538..dff56a3 100644
--- a/src/gpu/GrOnFlushResourceProvider.cpp
+++ b/src/gpu/GrOnFlushResourceProvider.cpp
@@ -34,7 +34,7 @@
auto renderTargetContext = GrRenderTargetContext::Make(
context, colorType, std::move(colorSpace), std::move(proxy),
- origin, props, false);
+ origin, props, true);
if (!renderTargetContext) {
return nullptr;
@@ -42,9 +42,6 @@
renderTargetContext->discard();
- // FIXME: http://skbug.com/9357: This breaks if the renderTargetContext splits its opsTask.
- fDrawingMgr->fOnFlushRenderTasks.push_back(sk_ref_sp(renderTargetContext->getOpsTask()));
-
return renderTargetContext;
}