New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 605107 link

Starred by 2 users
Status: WontFix
Owner:
peter@chromium.org
Closed: Jul 2017
Cc:
█ reed@chromium.org
amistry@chromium.org
jam@chromium.org
█ tomhud...@chromium.org
sa...@chromium.org
peter@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocking:
issue 595685



Sign in to add a comment

Enable SkBitmap to be used with Mojo in Blink

Project Member Reported by peter@chromium.org, Apr 20 2016 
Various Blink features are now moving all their renderer-sided code into Blink, communicating with the browser process directly using Mojo.

Mojo has two "variants" to support this: the regular ones using STL types, and Blink-specific ones backed by the WTF types. A mojom file can be created for either or both variants, but all interfaces it imports must be available in the same variant(s) as well.

SkBitmap has a Mojo interface defined in //skia/public/interfaces/, and thus has no WTF variant available. This means Blink code can't use SkBitmap in their Mojo interfaces, which, at least for notifications, we do need to.

A few things we could consider are:

  (1) Move the SkBitmap mojom files to Blink, generate bindings for both variants.
  (2) Create a second SkBitmap mojom interface in Blink, generate bindings for both variants.
  (3) Make //skia/(public/) depend on WTF, generate both variants there.

In order to minimize duplication, I'll draft a CL to see what (1) looks like.

The Skia mojom was introduced by Anand in this CL:
  https://codereview.chromium.org/1150083005

I raised this on chromium-mojo@ in the following thread:
  https://groups.google.com/a/chromium.org/forum/#!topic/chromium-mojo/d2eSTSM5OQw

Comment 1 by tomhud...@chromium.org, Apr 20 2016

Cc: tomhud...@chromium.org
Blink depends on Skia, while the Chrome browser process depends on Skia and shouldn't depend on Blink, right?

(1) introduces a browser -> blink dependency
(2) introduces duplicate code
(3) introduces a weird-if-not-techincally-circular dependency

(Understanding #3 is hampered by src/skia/ and third_party/skia/ being very different conceptually...; I think some of src/skia/ is currently for-the-browser and some is for-the-renderer, although maybe all is for-the-browser?)

Comment 2 by peter@chromium.org, Apr 20 2016 

The first option is fine for Mojo bindings, we're actively moving in that direction already. I am less sure about the type converters, which I'm toying with at the moment.

I'm not aware of any directories outside of Blink to depend on WTF directly, but it doesn't feel like a good option.

To be clear - other ideas and options are most welcome. Allowing a mojom file to depend on regular mojom files regardless of variant would arguably be cleanest, but the Mojo team decided against this.

Comment 3 by peter@chromium.org, Apr 21 2016 

I've got a working PoC here:

https://codereview.chromium.org/1906773003/

This works on both ends and I've managed to send a SkBitmap back and forth between Blink and //content/browser/. The large downside is that it's a mixture of (1) and (2)— it does duplicate the converter's code.

I'd very much appreciate ideas how we can make this work in a nicer way!

Comment 4 by amistry@chromium.org, Apr 22 2016

Cc: sa...@chromium.org

Comment 5 by sa...@chromium.org, Apr 22 2016 

In GN a blink variant is automatically generated: //skia/public/interfaces:interfaces_wtf (soon :interfaces_blink). For GYP you'll need to manually create a duplicate target in skia/skia.gyp.

For the type converters a TypeConverter partial specialisation that operates on either variant might help avoid code duplication.

Comment 6 by peter@chromium.org, Jul 4 2017

Status: WontFix (was: Started)
This is now supported.
►

Sign in to add a comment