Hook up CSSPaintValue::image to CSS Paint API callback.

third_party/WebKit/Source/core/css/CSSPaintImageGenerator.cpp

+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#include "core/css/CSSPaintImageGenerator.h"
+
+namespace blink {
+
+namespace {
+
+CSSPaintImageGenerator::CSSPaintImageGeneratorCreateFunction s_createFunction = nullptr;
+
+} // namespace
+
+// static
+void CSSPaintImageGenerator::init(CSSPaintImageGeneratorCreateFunction createFunction)
+{
+    ASSERT(!s_createFunction);
+    s_createFunction = createFunction;

[haraken, 2016/04/11 02:18:14]

It's a bit nasty to bypass the core/ => modules/ dependency using a global
variable. Alternately, can we use Supplement<WorkerClient>?

See how IndexedDBClient addresses the dependency problem:
https://codereview.chromium.org/1865213006/

[ikilpatrick, 2016/04/11 22:34:23]

I just wanted to check if this is what you meant before doing this:

Create a Supplementable inside CSSPaintImageGenerator i.e.

class CSSPaintImageGenerator : /* etc */ {
public:
    class SupplementableHost : public Supplementable<SupplementableHost> {
        static SupplentableHost& instance()
        {
            DEFINE_STATIC_LOCAL(/* etc */);
            return instance;
        }
        static const char* supplementName() { return
"CSSPaintImageGenerator::Factory"; }
        static CSSPaintImageGenerator* create(name, document, observer)
        {
            CSSPaintImageGenerator::Factory* factory =
                  static_cast<CSSPaintImageGenerator::Factory*>
                  (Supplement<CSSPaintImageGenerator::Factory>::from(instance(),
supplementName()));
            return factory->create(name, document, observer);
        }
    };

    class Factory {
        virtual CSSPaintImageGenerator* create(name, document, observer);
    }
};

And hook up in ModulesInitializer like:

void ModulesInitializer::initialize()
{
    CSSPaintImageGenerator::SupplementableHost.instance().provideSupplement(
        CSSPaintImageGeneratorImpl::Factory.instance(),
CSSPaintImageGenerator::SupplementableHost.supplementName());
}

[haraken, 2016/04/12 00:44:20]

Ah, thanks -- I now understand it would be more nasty than the current static
variable hack...

Final question: Can we use ChromeClient to bypass the dependency from core/ to
modules/?

  frame()->page()->chromeClient()->youCanCallWhateverMethodFromWebLayer();

ChromeClient is (one of the) standard ways to bypass the dependency from core/
to modules/.

[ikilpatrick, 2016/04/12 03:08:09]

So at CSSPaintValue create time we don't have access to the frame/page/etc. In
order to do this we'd need to pass in the LayoutObject for all the public
methods that core/ will do access on this class. For example for the
invalidationProperties:

public CSSPaintValue : /* etc */ {
public:
  const Vector<CSSPropertyID>& nativeInvalidationProperties(/* Need to pass in
LayoutObject/Page here? */);
};

Which is a bit confusing as to why you'd need a layoutobject/page/etc.

The nativeInvalidationProperties() method is probably going to be called at
ComputedStyle#needsPaintInvalidationObject which doesn't have access to these
things.

[haraken, 2016/04/12 04:02:43]

Thanks, I think our conclusion is that we need a better, more generalized
mechanism to bypass the core/ => modules/ dependency.

LGTM.

+}
+
+// static
+CSSPaintImageGenerator* CSSPaintImageGenerator::create(const String& name, Document& document, Observer* observer)
+{
+    ASSERT(s_createFunction);
+    return s_createFunction(name, document, observer);
+}
+
+CSSPaintImageGenerator::~CSSPaintImageGenerator()
+{
+}
+
+} // namespace blink