Re: [blink-dev] BlinkOn notes: Making Blink an awesome OSS project

[Tom Wiltzius]

On Fri, Oct 4, 2013 at 4:15 PM, Marshall Greenblatt <magree...@gmail.com> wrote:

On Oct 5, 2013, at 12:23 AM, Adam Barth <aba...@chromium.org> wrote:

On Fri, Oct 4, 2013 at 2:14 PM, Marshall Greenblatt <magree...@gmail.com> wrote:

On Oct 4, 2013, at 11:59 PM, Max Heinritz <m...@chromium.org> wrote:

We had a great session at BlinkOn about how make Blink an even better open source project. Notes below, also in this doc:

Actionable ideas highlighted in yellow -- feel free to claim ownership or forward to someone who might be interested.

Notes:

• Internal policy and process

• Goals of the “intent” system:

• Make it easy to start implementing and gathering feedback.

• Establish a high quality/compatibility threshold for shipping.

• Demos are cool

• Idea: add “link to a demo page” to Intent to Ship template. -- DONE

• Branches

• Good place for experiments.  Risk is on the implementor -- patches would need to be manually landed on trunk and still require approval.

• Idea: make a “how to work on a branch and make it useful” guide based on lazy block layout or Oilpan.

• “Last week in Blink intents”

• Should include threads that were resolved last week, in addition to new threads and unresolved threads

• Google and external companies

• “BlinkOn is great for asking questions that it wouldn’t make sense to ask on blink-dev.”

• If you have a question, it’s likely that others have the same question. Feel free to ask on blink-dev!

• Idea: start a Blink-focused Google Developers Live.

• Could be a good forum for BlinkOn-like interactions with senior engineers.

• We could have public moderator for folks to ask more informal questions.

• Moderated by Paul Irish.

• Targeted at Blink engineers and interested web developers.

• Getting patches reviewed is hard sometimes.

• Suggestion: reach out to individual reviewers to get their attention.

• blink-dev email volume

• Googlers don’t think there’s too much traffic; some non-Googlers find it overwhelming :)

• Idea: start a Blink blog.

• Could just aggregate posts from others

• If we do this, we should be sure there’s enough content

• Relationship with web developers [paulirish]

• blink-dev => we want more engagement from web developers.  

• Idea: A better weekly intent summary.

• Issue tracker

• We do a terrible job triaging today.

• Regressions should be flagged and given higher priority.

• Idea: assign Blink engineers a rotation schedule for bug triaging.

• Idea: write an article about how to reduce a test case.  Link to it from the bug template.  Maybe make a video?

• Web developer surveys

• BlinkOn => ContentShellCon [peter]

• The lines betweens Blink and the rest of Chromium are blurring.  Non-Google Blink contributors are embedding at the Content Shell layer.

• Think of embedding Blink or content shell as being like maintaining a fork.

• Messaging has been: “Blink is not stable for use in other projects, try content shell.  But that’s not really stable either.”

• Chromium Embedded Framework is great but the maintainers have to do work to make it usable.

I'm the maintainer of Chromium Embedded Framework. It's currently used by 50+ companies with over 100 million installations world-wide. Needless to say I find this bullet point somewhat surprising. Can you expand on it or direct me to the relevant discussion? :)

Unfortunately, the discussion happened in one of the smaller rooms at BlinkOn and so wasn't recorded.

The discussion was mostly about what we can do to make your life easier.  We talked a bit about whether we wanted to create a stable API, but I don't think we're ready to take that step yet.  I mentioned that I thought you took the right approach with CEF of building your own stable API to insulate your customers from churn in Chromium's APIs.  We then talked a bit about where there were things we could do short of building a stable API that would make it easier for CEF to provide a stable API.

I'm very interested in your perspective on these topics.  You certainly know much more about them than I do!  :)

Sounds like a good discussion! Below are some requests that come to mind (not ordered in any particular way). They're not all 100% blink-specific, and some might be undesirable or overly challenging from a technical standpoint.

1. Better documentation of web-facing behavior changes between versions. It would be nice if we could provide a bullet list of what's changed from a web-facing perspective (CSS, JS and layout) between specific build versions without having to read through thousands of commit messages. For example, it's common that a company will be upgrading from Chromium version X to X+4 (about 40k commits) and will want to know in advance what changes to expect.

2. The ability to disable features at compile-time. Many applications with embedded browsers only need a subset of web features and would ideally want to reduce binary distribution size by removing the unused features. Also, some features require native or WebUI implementations in Chromium that may not be immediately available in CEF (like color picker and datalist), so it would be better to disable those features instead of leaving them broken. (I know that the project is currently moving away from compile-time flags.)

3. Support for embedded accelerated compositing. CEF currently supports a windowless mode where the final rendered result is provided to the embedder as a pixel buffer. This works well but currently only supports the software rendering code path. It would be great to have a stable code path that supports hardware acceleration while also placing the final composited result in a texture (or similar) in the browser process.

We will need to find some sort of solution for this, because the software rendering code path is going away as we try to consolidate modes to be all compositing all the time.

One option would be to allow you to just grab the final composited results from the software compositor in the browser process before it gets blitted to the screen. I'm about to send a note about the graphics roadmap to all of chromium-dev, but the best place to have this discussion is on graphics-dev@.

 

4. Interrupts for V8 JavaScript execution. I don't believe there's a way currently to terminate runaway V8 execution without also terminating the whole render process.

5. Better control over DOM and V8 memory usage. Provide support for capping memory usage and/or forcing the GC to free as much memory as possible on demand. Also, possibly more aggressive cleanup of hidden DOM nodes so applications that never reload don't accidentally blow up memory usage by constantly adding to (and never properly removing from) the DOM tree.

6. Support for clean shutdown/restart in the same browser process. Blink currently has static/global objects that make it impossible to unload and reload Chromium in the browser process. (This problem may go away once the browser process dependency on Blink is fully removed.)

7. Consistently apply restrictions for CORS-enabled schemes. There are some places in Blink where we hard-code checks for HTTP[S] instead of honoring the WebSecurityPolicy registrations.

8. Build configuration that is app store compatible. Apple and (to a lesser degree) Microsoft have restrictions on the system APIs that can be used by submitted apps. It would be nice to offer a build that can pass the app store requirements.

9. Better printing support. Both IE and Firefox seem to have better formatting options and print quality. It would also be nice to share a print preview implementation with Chromium.

10. A way to disable debug build assertions in blink code (but keep debug assertions in Chromium code). Embedded users generally don't care about non-fatal layout problems like unexpected invalidations or sub-pixel rendering issues. (Maybe this already exists?)

Thanks,

Marshall

Adam

• Idea: better explain the process of embedding Blink / Content Shell.

• Idea: have the next conference focus on both Blink and Content Shell.  Invite more folks from the Chrome team.

• Idea: allow bug reporters to attach a video of their screen via Hangouts.

• Idea: better visual bisect tools.

• Idea: link to web developer surveys from a little icon in DevTools.

• Idea: encourage triaging by external folks.

• Licensing

• No plans to change.  If we wanted, we could move some parts of the code to libraries to change the licensing.

• Refactoring

• It’s currently hard for external contributors to feel involved or capable of making major refactorings.

• External folks should establish familiarity and credibility will smaller changes first.

• Idea: make non-chromium.org accounts first-class citizens on Rievteld

• Currently, @google.com and @chromium.org accounts have special privileges, hard coded in the database.

• Some contributors are required to use their corporate emails.

• Would be nice if they could be first-class citizens on Rievteld too.

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

[Tom Wiltzius]

Whoops, just saw that Adam split this thread out. blink-dev to bcc, anyone interested please feel free to follow along on graphics-dev (which anyone is welcome to join if they're interested in Chromium's graphics stack)

[Marshall Greenblatt]

The approach that CEF currently uses for windowless rendering involves:

1. Setting WebPreferences.accelerated_compositing_enabled to false.

2 Providing a custom implementation of WebContentsView, RenderWidgetHostView and BackingStore.

3. Passing the BackingStore buffer to the embedder in RenderWidgetHostView::Paint().

I imagine this approach is using the software compositor currently. Will it continue to work after removal of the software rendering path?

Thanks,

Marshall

[Darin Fisher]

That approach is what we refer to as the legacy software renderer. The software compositor is a new thing that attempts to provide a software backend for the hardware accelerated compositing path. We'd like to delete the legacy software renderer once the software compositor is good enough to replace it. It sounds like this will be disruptive to CEF. It would be good for you to look into using the software compositing paths sooner rather than later.

Regards,

-Darin

[Darin Fisher]

Note: unlike the legacy software renderer, the software compositor supports 3D CSS transforms. It can also be more efficient for some work loads (and hopefully all workloads in the future).

-Darin

[Marshall Greenblatt]

On Oct 6, 2013, at 11:44 PM, Darin Fisher <da...@chromium.org> wrote:

That approach is what we refer to as the legacy software renderer. The software compositor is a new thing that attempts to provide a software backend for the hardware accelerated compositing path. We'd like to delete the legacy software renderer once the software compositor is good enough to replace it. It sounds like this will be disruptive to CEF. It would be good for you to look into using the software compositing paths sooner rather than later.

Thanks Darin. Can you point me to the relevant design docs and/or code that I need to implement to use the software compositing path?

[John Bauman]

The software compositor is currently in a bit of flux. Once https://codereview.chromium.org/25942002/ is checked in you'll be able to hook into the SoftwareFramebuffer. However, for aura we'll probably be switching over to delegated rendering/ubercompositor by default, so that will change how all this behaves. It might be best to create a RenderWidgetHostViewFrameSubscriber or similar to capture the frame from the RenderWidgetHostViewAura; that abstracts out many of the details and gives back a media::VideoFrame.

[Tom Wiltzius]

Marshall, we have a variety of documentation on various related topics at www.chromium.org/developers/design-documents/chromium-graphics

however the software compositor isn't covered there very explicitly. John is the expert on this area these days, and in general if you have questions about your approach please feel free to email graphics-dev