Any clue as to what is causing this issue?

This is also affecting Chromecast with the --show-fps-counter flag.

On a release build this eventually hits a CHECK later on in blink:[15538:15538:FATAL:local_window_proxy.cc(233)] Check failed: !context.IsEmpty()

Not sure this information helps but I can reproduce this on ToT (68.0.3440.0) in a locally built Linux content_shell by running:
./content_shell --enable-gpu-rasterization --show-fps-counter

I bisected it down to the revision mentioned in the description.

Antoine, is this something you could investigate?

Some more clues, by changing the following support_grcontext to true I don't get the dcheck anymore:
https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?l=2095&rcl=4519c32f528e079f25cb2afc594ecf625f943782

But I guess the proper fix is to use the worker_context_provider in cc::HeadsUpDisplayLayerImpl::UpdateHudTexture instead of the context_provider when gpu raster is enabled?

->backer, could you take a look?

This DCHECK fires when you try to use GrContext on a context provider that was initialized with "supports_grcontext = false".  It should just be a matter of flipping that bit at the call site where the context provider is set-up.  I'm not familiar with this code, so I'm not sure which calls site is the right one.

Perhaps this one:
https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?dr=CSs&g=0&l=2095

Fyi, I pushed a CL with the suggested fix:
https://chromium-review.googlesource.com/c/chromium/src/+/1078267

Looking...

It's also sufficient to disable this branch (always set |gpu_raster| to false). https://cs.chromium.org/chromium/src/cc/layers/heads_up_display_layer_impl.cc?rcl=d9732ad00f8dd2564a6283a67156697cfe85dbac&l=267

I tested by hand and ran cc_unittests. I think that it would be better to do this because we eventually want to remove all GrContext from the renderer. But eventually is a long time from now. And perhaps the HUD layer hurts performance when we use CPU raster the HUD layer but GPU raster the content.

+vmiura

Victor: Do you want to nix the HUD layer dependency on GrContext now or later?

+enne who may have an opinion.

Agreed with backer that we want to remove all GrContext usage from the renderer.

The easiest solution does seem to be to just use software mode always as backer suggests (without removing all the other code that it supports).  Given that this DCHECK means that show paint rects from devtools is likely not working anymore, I think it's important to land a short term fix.

A better solution might be to lock and use the worker context provider.  We'd also need a third branch in that code to support oop raster when that's available.

Awkward cuz we just added hardware raster to the HUD, since the texture upload was destroying the fps meter's usefulness. Can it use OOPR?

It could use ganesh now if it used the worker context provider.  We'd just also need to also fix it for oopr.

Consensus on #chromium is that the change in comment #7 should land and be backported to m68.

Then on ToT we can figure out how to remove GrContext from compositor thread.
Some suggestions for that centered around:

- maybe using worker context
- maybe using OOP-R
- maybe modifying RasterInterface to make the use of GPU raster or OOP-R easier from clients

The CL is in the CQ now. Regarding m68, I have no idea how you trigger backports so I think it would be best if one of you could help me with that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/905b8cac7b58d60a0003c4c413da212b37889e53

commit 905b8cac7b58d60a0003c4c413da212b37889e53
Author: Roger Johannesson <rogerj@vewd.com>
Date: Thu May 31 13:28:54 2018

Enable GrContext support in the shared main thread context provider

This prevents a DCHECK when running with either --show-fps-counter or
--show-paint-rects together with --enable-gpu-rasterization. The DCHECK
is triggered by cc::HeadsUpDisplayLayerImpl::UpdateHudTexture that makes
use of the GrContext when gpu rasterization is enabled.

Bug:  837246 ,  810159 
Change-Id: I74d2b1390d975dd783736bb1c12114ed4c7cbb0a
Reviewed-on: https://chromium-review.googlesource.com/1078267
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Reviewed-by: Justin Novosad <junov@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Cr-Commit-Position: refs/heads/master@{#563207}
[modify] https://crrev.com/905b8cac7b58d60a0003c4c413da212b37889e53/content/renderer/render_thread_impl.cc

DCHECK no longer fires.