Bug 95917 - [chromium] Need a API to upload Android image resources from the embedder
Summary: [chromium] Need a API to upload Android image resources from the embedder
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-05 17:28 PDT by Tien-Ren Chen
Modified: 2013-04-08 11:12 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tien-Ren Chen 2012-09-05 17:28:01 PDT
The edge effect layers need to acquire the glow textures from Android framework. (and potentially the shadow decoration needs it too? sievers@)

We can't do it from the WebKit side due to the lack of Dalvik VM access, so we need an API to upload it from the embedder side. Currently in my downstream code I add a new callback in WebWidgetClient like this:

class WebWidgetClient {
    // Android only. Used to retrieve drawable resources from system theme.
    virtual void getDrawableResources(WebImage* out, const char* name) { }
};

WebViewImpl::WebViewImpl(WebViewClient* client)
{
    WebImage glowImage;
    client->getDrawableResources(&glowImage, "android:drawable/overscroll_glow");
    m_edgeEffectPlatformLayer = EdgeEffectLayerChromiumAndroid::create(glowImage.getSkBitmap());
}

Not sure if it is the best way to implement the thing. Let's discuss how to upstream this.
Comment 1 James Robinson 2012-09-05 17:34:35 PDT
Adrienne has a design doc about how to approach this for the compositor.  We also have a general mechanism for loading resources into WebKit used by the theming logic on all platforms (including android).  I would look at those and see if they meet your needs before proposing something new.
Comment 2 Tien-Ren Chen 2012-09-05 17:45:16 PDT
(In reply to comment #1)
> Adrienne has a design doc about how to approach this for the compositor.  We also have a general mechanism for loading resources into WebKit used by the theming logic on all platforms (including android).  I would look at those and see if they meet your needs before proposing something new.

For the compositor part I believe you're referring to the DecorationManager thing? Yes that would definitely be useful.

Could you give me a pointer what to look for the theming logic? Is it the WebKitPlatformSupport class? Thanks!
Comment 3 James Robinson 2012-09-05 18:41:33 PDT
http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/Platform/chromium/public/Platform.h&exact_package=chromium&q=Platform.h&l=261 exists and it used by, for instance, Image::loadPlatformResource() which looks similar to your need.
Comment 4 Tien-Ren Chen 2012-09-06 13:14:05 PDT
(In reply to comment #3)
> http://code.google.com/searchframe#OAMlx_jo-ck/src/third_party/WebKit/Source/Platform/chromium/public/Platform.h&exact_package=chromium&q=Platform.h&l=261 exists and it used by, for instance, Image::loadPlatformResource() which looks similar to your need.

Sounds good. I think I don't need WebKit-side change then.

I will do something like this instead:

chrome/webkit/glue/webkitplatformsupport_impl.cc:

WebData WebKitPlatformSupportImpl::loadResource(const char* name) {
    ....
#if defined(OS_ANDROID)
    if (!strncmp(name, "android:drawable/", 17))
        return loadAndroidDrawable(name);
#endif
    ....
}

Or do you prefer me to subclass it as WebKitPlatformSupportImplAndroid?

Another thing I'm not sure about is how to pass a decoded bitmap in WebData. The API seems to be designed to load raw files. I could pack the bitmap in some simple struct then pass it as the WebData payload, but I feel it will become a maintenance WTF later on.
Comment 5 Peter Beverloo 2013-04-08 11:12:27 PDT
Resolving as WontFix given that Chromium moved to Blink.