are crashing intermittently on all platforms due to an assert. This looks to have been exposed by:
which passes through the acceleratePainting flag to settings. Sample Linux crash stack:
crash log for DumpRenderTree (pid 6766):
STDERR: [6766:6766:915311230:ERROR:gles2_cmd_decoder.cc(5109)] GL ERROR :GL_INVALID_OPERATION : glFramebufferTexture2D: unknown texture
STDERR: base::debug::StackTrace::StackTrace() [0x82d82a8]
STDERR: base::(anonymous namespace)::StackDumpSignalHandler() [0x82c17bd]
STDERR: WebCore::FrameBufferSkPictureCanvasLayerTextureUpdater::updateTextureRect() [0x88caa79]
STDERR: WebCore::FrameBufferSkPictureCanvasLayerTextureUpdater::Texture::updateRect() [0x88cae62]
STDERR: WebCore::(anonymous namespace)::UnthrottledTextureUploader::uploadTexture() [0x89088d4]
STDERR: WebCore::CCTextureUpdater::update() [0x88fe628]
STDERR: WebCore::CCSingleThreadProxy::doCommit() [0x88fcf1d]
STDERR: WebCore::CCSingleThreadProxy::commitAndComposite() [0x88fcfcc]
STDERR: WebCore::CCSingleThreadProxy::compositeAndReadback() [0x88fd48f]
STDERR: WebCore::CCLayerTreeHost::compositeAndReadback() [0x88db3d4]
STDERR: WebKit::WebLayerTreeView::compositeAndReadback() [0x8104c1b]
STDERR: WebKit::WebViewImpl::doPixelReadbackToCanvas() [0x80c61a8]
STDERR: WebKit::WebViewImpl::paint() [0x80c65aa]
STDERR: WebViewHost::paintRect() [0x8089750]
STDERR: WebViewHost::paintInvalidatedRegion() [0x80898b1]
STDERR: TestShell::dump() [0x80852d6]
STDERR: TestShell::testFinished() [0x80858c9]
STDERR: LayoutTestController::WorkQueue::processWorkSoon() [0x8066a65]
STDERR: WebViewHost::locationChangeDone() [0x808a0e8]
STDERR: WebKit::FrameLoaderClientImpl::dispatchDidFinishLoad() [0x80ef741]
STDERR: WebCore::FrameLoader::checkLoadCompleteForThisFrame() [0x8b68dfd]
STDERR: WebCore::FrameLoader::checkLoadComplete() [0x8b68fd9]
STDERR: WebCore::DocumentLoader::finishedLoading() [0x8b51822]
STDERR: WebCore::MainResourceLoader::didFinishLoading() [0x8b79399]
STDERR: WebCore::ResourceLoader::didFinishLoading() [0x8b8e166]
STDERR: WebCore::ResourceHandleInternal::didFinishLoading() [0x9817dab]
STDERR: webkit_glue::WebURLLoaderImpl::Context::OnCompletedRequest() [0x92f872e]
STDERR: (anonymous namespace)::RequestProxy::NotifyCompletedRequest() [0x93983f6]
STDERR: base::internal::Invoker<>::Run() [0x939860b]
STDERR: MessageLoop::RunTask() [0x82b5080]
STDERR: MessageLoop::DeferOrRunPendingTask() [0x82b5722]
STDERR: MessageLoop::DoWork() [0x82b5a81]
STDERR: base::MessagePumpGlib::HandleDispatch() [0x82d2018]
STDERR: (anonymous namespace)::WorkSourceDispatch() [0x82d2057]
STDERR: base::MessagePumpGlib::RunWithDispatcher() [0x82d24e9]
STDERR: base::MessagePumpGlib::Run() [0x82d207e]
STDERR: MessageLoop::RunInternal() [0x82b043e]
STDERR: base::RunLoop::Run() [0x82c1a69]
STDERR: MessageLoop::Run() [0x82af60e]
STDERR: webkit_support::RunMessageLoop() [0x81cbff7]
STDERR: TestShell::waitTestFinished() [0x8085999]
STDERR: TestShell::runFileTest() [0x8083f9f]
STDERR: runTest() [0x805d3f3]
STDERR: main [0x805d9d3]
Accelerated painting used the compositor context to create and upload the tile textures. Now it seems we use two contexts - one that creates the texture and another to upload it. Although the texture is shared by the two contexts, it is not immediately available after creation to the context that uploads it. Flushing the context that creates it fixes the problem.
Created attachment 160818 [details]
Created attachment 160822 [details]
sync'd with TOT.
The Framebuffer texture updater isn't actually used unless enabled by command-line flags anywhere. At a minimum you will need to do something on other code paths such as BitmapCanvasLayerTextureUpdater (the default updater). But presumably you want to flush the sharedContext used for filters, not the context being used for upload, and we should do this once before any uploading takes place? Maybe CCTextureUpdateController?
Oh I may be thinking backwards, the texture is created by our resource provider, but we're uploading using ganesh? Too used to the other way around. If so then ignore my last comment.
Right. This class is exclusively used by accelerated-painting path. AFAIK BitmapCanvasLayerTextureUpdater is not affected by using two contexts. In fact I am not even aware when we switched to using two contexts. I am not flushing the context that uploads. I am flushing the context that creates the textures. We could add a flush here: http://trac.webkit.org/browser/trunk/Source/WebCore/platform/graphics/chromium/cc/CCResourceProvider.cpp#L124
(right after the texture is created), but that would affect other texture-updaters as well - even the ones that do not need it.
Yeh this seems legit as presented, sorry for my misunderstanding!
Comment on attachment 160822 [details]
Attachment 160822 [details] did not pass chromium-ews (chromium-xvfb):
Comment on attachment 160822 [details]
Attachment 160822 [details] did not pass cr-android-ews (chromium-android):
Created attachment 160998 [details]
sync'd again with TOT.
james: can you review it?
Comment on attachment 160998 [details]
Clearing flags on attachment: 160998
Committed r127294: <http://trac.webkit.org/changeset/127294>
All reviewed patches have been landed. Closing bug.
Created attachment 162592 [details]
Adjusting test expectations after watching test bots and flakiness dashboard. It seems the earlier patch indeed fixed the problem.
Stephen: Could you approve the TestExpectations patch. Thanks.
Don't attach new patches to closed bugs - open a new bug for new patches if you want a review. For this, I'd just commit it.