The draw calls that aren't appearing seem to be exactly the draw calls in GraphicsContextCanvas::ReleaseIfNeeded(), namely

    canvas_->save();                                                                     
    canvas_->setMatrix(SkMatrix::I());  // Reset back to device space.                   
    canvas_->translate(bounds.x() + bitmap_offset_.x(),                                  
                       bounds.y() + bitmap_offset_.y());                                 
    canvas_->scale(1.f / bitmap_scale_factor_, 1.f / bitmap_scale_factor_);              
    canvas_->drawBitmap(subset, 0, 0);                                                   
    canvas_->restore();

(still digging, but that may be relevant).

Mmh, the couple of lines before that may be relevant too:

    // Find the bits that were drawn to.                                                 
    SkIRect bounds = ComputeDirtyRect();                                                 
    SkBitmap subset;                                                                     
    if (!offscreen_.extractSubset(&subset, bounds)) {                                    
      return;                                                                            
    }                                                                                    
    subset.setImmutable();  // Prevents a defensive copy inside Skia.                    
    canvas_->save();
    canvas_->setMatrix(SkMatrix::I());  // Reset back to device space.
    canvas_->translate(bounds.x() + bitmap_offset_.x(),
                       bounds.y() + bitmap_offset_.y());
    canvas_->scale(1.f / bitmap_scale_factor_, 1.f / bitmap_scale_factor_);
    canvas_->drawBitmap(subset, 0, 0);                                                   
    canvas_->restore();

> However, if you start the browser with a "Generic RGB" profile,
> then change to sRGB, the button will not appear. This makes me
> think that the bug is in Chrome (setting up some global state
> that refers to the color profile).

Red herring.

This is because changing the display's color space didn't cause the cached values in the browser to be re-computed. If you force them to be re-computed, it works.

I've lost the scent for tonight.

If I skip the call to SkImage_Raster::onMakeColorSpace and return the original SkImage, then I get the correct result. Also if I remove the makeColorSpace call on the first line of SkImage_Raster::onMakeColorSpace, then I also get the correct result.

I haven't figured out if we're skipping drawing in SkImage_Raster::onMakeColorSpace or later in the bowels of SkGpuDevice::drawBitmap.

Looks like a legacy-versus-not-legacy issue the divergence is at
  sk_sp<GrTextureProxy> GrUploadPixmapToTextureProxy(GrResourceProvider* resourceProvider,
                                                     const SkPixmap& pixmap,
                                                     SkBudgeted budgeted) {
      if (!SkImageInfoIsValidRenderingCS(pixmap.info())) {
          return nullptr; 
And we're failing SkImageInfoIsValidRenderingCS because the check on

   70  	    if (info.colorSpace() &&
   71  	       (!info.colorSpace()->gammaCloseToSRGB() && !info.colorSpace()->gammaIsLinear())) {
-> 72  	        return false;
   73  	    }

The SkImageInfo for the bitmap (and then pixmap) has the destination color space (non-sRGB) from the makeColorSpace done by the Xform canvas. So, somewhere in the below stack, we need to skip the color space check.

  GrUploadPixmapToTextureProxy(resourceProvider=0x00007feb3a2426d0, pixmap=0x000070001138db88, budgeted=1) + 66 at SkGr.cpp:150
  GrUploadBitmapToTextureProxy(resourceProvider=0x00007feb3a2426d0, bitmap=0x000070001138e560) + 156 at SkGr.cpp:73
  GrBitmapTextureMaker::refOriginalTextureProxy(this=0x000070001138e540, willBeMipped=false, dstColorSpace=0x0000000000000000) + 354 at GrBitmapTextureMaker.cpp:44
  GrTextureMaker::refTextureProxyForParams(this=0x000070001138e540, params=0x000070001138deb8, dstColorSpace=0x0000000000000000, texColorSpace=0x000070001138de80, scaleAdjust=0x000070001138deb0) + 391 at GrTextureMaker.cpp:31
  GrTextureMaker::createFragmentProcessor(this=0x000070001138e540, textureMatrix=0x000000011cfe5130, constraintRect=0x000070001138e368, filterConstraint=kYes_FilterConstraint, coordsLimitedToConstraintRect=true, filterOrNullForBicubic=0x000070001138e148, dstColorSpace=0x0000000000000000) + 296 at GrTextureMaker.cpp:84
  SkGpuDevice::drawTextureProducerImpl(this=0x00007feb3909cc00, producer=0x000070001138e540, clippedSrcRect=0x000070001138e368, clippedDstRect=0x000070001138e358, constraint=kStrict_SrcRectConstraint, viewMatrix=0x000070001138e5e8, srcToDstMatrix=0x000070001138e3a0, clip=0x000070001138e4e8, paint=0x000070001138ed38) + 988 at SkGpuDevice_drawTexture.cpp:206
  SkGpuDevice::drawTextureProducer(this=0x00007feb3909cc00, producer=0x000070001138e540, srcRect=0x0000000000000000, dstRect=0x0000000000000000, constraint=kStrict_SrcRectConstraint, viewMatrix=0x000070001138e5e8, clip=0x000070001138e4e8, paint=0x000070001138ed38) + 720 at SkGpuDevice_drawTexture.cpp:143
  SkGpuDevice::drawBitmap(this=0x00007feb3909cc00, bitmap=0x000070001138e7a0, m=0x000070001138e7d8, paint=0x000070001138ed38) + 1315 at SkGpuDevice.cpp:908
  SkGpuDevice::drawImage(this=0x00007feb3909cc00, image=0x00007feb3a50c0a0, x=0, y=0, paint=0x000070001138ed38) + 1455 at SkGpuDevice.cpp:1395
  SkCanvas::onDrawImage(this=0x00007feb3909d800, image=0x00007feb3a50c0a0, x=0, y=0, paint=0x000070001138ed38) + 1354 at SkCanvas.cpp:2208
  SkCanvas::drawImage(this=0x00007feb3909d800, image=0x00007feb3a50c0a0, x=0, y=0, paint=0x000070001138ed38) + 99 at SkCanvas.cpp:1758
  SkColorSpaceXformCanvas::onDrawImage(this=0x00007feb3909ea00, img=0x00007feb3a216160, l=0, t=0, paint=0x00007feb3a210780) + 366 at SkColorSpaceXformCanvas.cpp:142
  SkCanvas::drawImage(this=0x00007feb3909ea00, image=0x00007feb3a216160, x=0, y=0, paint=0x00007feb3a210780) + 99 at SkCanvas.cpp:1758

Got it, thanks for digging into this...

SkImageInfoIsValid() has recently become SkImageInfoIsValidAllowNumericalCS() and SkImageInfoIsValidRenderingCS() for cases like these.  We probably don't need to be using the stricter version here, I'll try to write something.

The following revision refers to this bug:
  https://skia.googlesource.com/skia/+/dedac85b4f08546e92143d96c13b753cb1b80e23

commit dedac85b4f08546e92143d96c13b753cb1b80e23
Author: Matt Sarett <msarett@google.com>
Date: Mon May 15 13:46:50 2017

Allow numerical color spaces with legacy rendering

Bug:  720083 
Change-Id: Ibd4dbf6ee95ac14857e8280a441f81976710e5e8
Reviewed-on: https://skia-review.googlesource.com/16700
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Matt Sarett <msarett@google.com>

[modify] https://crrev.com/dedac85b4f08546e92143d96c13b753cb1b80e23/src/image/SkImage_Gpu.cpp
[modify] https://crrev.com/dedac85b4f08546e92143d96c13b753cb1b80e23/src/gpu/SkGr.h
[modify] https://crrev.com/dedac85b4f08546e92143d96c13b753cb1b80e23/src/gpu/GrBitmapTextureMaker.cpp
[modify] https://crrev.com/dedac85b4f08546e92143d96c13b753cb1b80e23/src/gpu/SkGr.cpp
[modify] https://crrev.com/dedac85b4f08546e92143d96c13b753cb1b80e23/src/image/SkImage_Lazy.cpp
[modify] https://crrev.com/dedac85b4f08546e92143d96c13b753cb1b80e23/src/core/SkImageInfoPriv.h

Chris, can you let me know if this is fixed?  I was unable to reproduce on Linux.

That particular test is working, but I'm still seeing some issues with check-boxes on crbug.com. Attached an image.

Native controls are very Mac-specific. And on Mac it requires running with
  --enable-color-correct-rendering
  --force-color-profile=bt2020-gamma18

Note that this is only on Canary -- I haven't tested ToT yet.

I'm re-building ToT to see if it is fixed there as well.

Deleted: crbug-controls.png 352 KB

	crbug-controls.png 352 KB View Download

Got it, thanks for the info.  The fix only rolled into Chrome two hours ago.

Yup, can confirm that ToT has the check boxes fixed (hmm, I wonder what fixed the buttons earlier).