Intent to add Blink->Chromium dependency: Source/platform/ -> cc/

[Jeremy Roman]

Doc: https://docs.google.com/document/d/1Jfwwx29XaGkfpARfiO8dQd7lQYVs3znrSc3DdKZhCj8/edit?usp=sharing

tl;dr: I'd like to allow including cc/ from Source/platform/[graphics/], so that we can call cc from Blink's compositing support code.

This will probably imply access to a handful of classes in base/ (such as scoped_ptr and scoped_refptr) and ui/gfx/ (such as gfx::Rect), which are used in cc's public interface. Their use should be confined to just before/after calling into cc.

Currently the only path requires mirroring cc's interfaces in public/platform/ and then implementing bindings in cc/blink/, converting/wrapping argument types in the process.

[Kentaro Hara]

The platform/graphics/ => cc/ dependency sounds nice to me.

--

Kentaro Hara, Tokyo, Japan

[Fady Samuel]

Please, let's be cautious before making drastic changes here. There are other Blink embedders in the Chromium repo, such as Mandoline.

Fady

[Kentaro Hara]

From the perspective of dependencies from Blink to Chromium, what's a requirement for Mandoline?

[Jeremy Roman]

On Fri, Sep 25, 2015 at 10:42 AM, Fady Samuel <fsa...@chromium.org> wrote:

Please, let's be cautious before making drastic changes here. There are other Blink embedders in the Chromium repo, such as Mandoline.

The initial target here is more things that are in cc/blink/ than things that are in content/. It's surprising to me (though I now see that it is the case) that components/html_viewer (i.e. Mandoline) forces the cc-blink interaction to be different. This kind of overriding would presumably be hit by other refactors, such as SPv2, which affect how the compositor interacts with Blink. Why is Mandoline an agent in these interactions, when its current counterpart, content, isn't?

[Fady Samuel]

I can't speak to all the differences but one reason we differ from cc/blink/ is Mandoline "Views" are tightly coupled to Surfaces. In Mandoline, a CompositorFrame is submitted to a View.

We can work toward unified cc/blink usage. I'm not opposing anything in your proposal just yet. I need to think about it more carefully first, and see how this aligns with our future plans in Mandoline.

Fady

[Dimitri Glazkov]

Mandoline is great and is a natural next step to evolve our IPC plumbing. However, at this point, we need to be careful that your work doesn't slow down or interfere with the mission-critical work of the rest of the team.

:DG<

Fady

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.
To post to this group, send email to pain...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAMZzjTkwBP96grxdnqQfPYh7F1DEF7H70Q4NbHHk%3DOJjqU-OqA%40mail.gmail.com.

[Chris Harrelson]

I like this proposal. We should be careful when implementing to avoid problems (some potential problems are mentioned in the doc or its comments), but I think it's sound and a good step forward.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Elliott Sprehn]

+1, it seems very reasonable to merge the two glue layers. btw there seems to be two conflicting statements here and in the doc, is this only going to be in platform/graphics/ or in the rest of platform/ as well?

I don't think we should block on Mandoline, Paint Slimming is looking to ship big changes in the next two quarters, we need to prioritize their success and this should make their lives easier. :)

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.
To post to this group, send email to pain...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAOMQ%2Bw_NPDcOYC4wBTB%2BvrQTZBR4CWNHMVoyd1UCjEdy0nd2Dg%40mail.gmail.com.

[Jeremy Roman]

I'd originally intended to add the DEPS rule to Source/platform/ (because there's currently no Source/platform/graphics/DEPS), but based on haraken's feedback I'm willing to put restrict it to the subdirectories of Source/platform/ that it applies to (mostly graphics/, but perhaps also geometry/ for conversion utilities).

[Alex Clarke]

I'd really love to have base::TimerTicks in platform/  there's been several times (including today) where I got the units wrong when passing a time from blink to chrome.  Can we have that dependency?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Dana Jansens]

On Fri, Sep 25, 2015 at 7:42 AM, Fady Samuel <fsa...@chromium.org> wrote:

Please, let's be cautious before making drastic changes here. There are other Blink embedders in the Chromium repo, such as Mandoline.

The cc/blink/ bindings exist for the sole purpose of adding a hard virtual indirection between blink and cc. There's no real benefit for this now, we should drop this bindings layer and blink can use cc:: directly, just as ui/compositor/ or content/ does.

Mandoline already lives in the chromium repo. If it wants to use cc it should do it directly also, not through the cc/blink/ interface.

 

Fady

On Fri, Sep 25, 2015 at 10:29 AM, Jeremy Roman <jbr...@chromium.org> wrote:

Doc: https://docs.google.com/document/d/1Jfwwx29XaGkfpARfiO8dQd7lQYVs3znrSc3DdKZhCj8/edit?usp=sharing

tl;dr: I'd like to allow including cc/ from Source/platform/[graphics/], so that we can call cc from Blink's compositing support code.

This will probably imply access to a handful of classes in base/ (such as scoped_ptr and scoped_refptr) and ui/gfx/ (such as gfx::Rect), which are used in cc's public interface. Their use should be confined to just before/after calling into cc.

Currently the only path requires mirroring cc's interfaces in public/platform/ and then implementing bindings in cc/blink/, converting/wrapping argument types in the process.

LGTM as a cc owner

 

--
You received this message because you are subscribed to the Google Groups "paint-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to paint-dev+...@chromium.org.
To post to this group, send email to pain...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/paint-dev/CAMZzjTkuwGAat01qZZeN%3Di-GN-xLoyRUwf-s_gD_-DnYNTAREQ%40mail.gmail.com.

[Elliott Sprehn]

Great, lets start with the finer granularity of graphics/ and geometry/ to start (provided adding the DEPS in graphics/ isn't too hard) and expand from there. 

[Fady Samuel]

sgtm, thanks Dana!

Fady