Blink 2014 Goal Brainstorming

[Eric Seidel]

Some of the web platform team at Google recently met to plan for 2014.  I’d like to share some of our thoughts with the larger Blink community and solicit your own.

Web usage continues to shift from desktop to mobile.  Yet the mobile web remains far from reaching its potential -- in part because web engines (e.g. Blink) are not nearly as good on performance-constrained devices as they need to be.  To be successful on mobile, Blink must exit 2014 much more mobile-awesome.

Primarily this means improving Blink’s performance on less-powerful devices.  Blink should be hands-down the best performing mobile web engine.  We must achieve:

• Constant improvement to our core metrics

• Smoothness (scrolling & 60hz animation)

• Input Responsiveness

• Initial Load Time

• #1 on (credible/realistic) mobile web benchmarks

• Reduced memory consumption

• Lowest power consumption

Additionally we need to continue to improve the mobile web platform itself -- make it easy for authors to ship fast, awesome web apps.  In 2014 we plan to:

• Expose capabilities on the open-web competitive to “native” offerings

• Responsive images

• ServiceWorker

• Improved permissions model on the open-web

• Better-than-AppCache Offline

• Push notifications

• Device capabilities (Screen Orientation, Presentation API, etc.)

• Empower better App frameworks by rationalizing the platform layering [1]

• Web Animations, Pointer Events, Custom Elements, etc.

• Improve our own (and enable others to build) mobile-focused web developer tools

• Make it easy to find fast paths and figure out when/why you fall off

• Expose mobile design & performance insights in DevTools.

• Enable building modern batteries-included developer workflows for the Web (e.g. crash reporting, package management, IDE, testing infrastructure)

• Create, share and consume our guidelines for making responsive mobile apps

Finally, the long-term health of both the web platform and the Blink project must always be a top priority.  In 2014 we need to:

• Find ways to deprecate & remove large platform features with minimal breakage.

• Merge Blink repository into Chromium without loss of history.

• Add safer (garbage collected) memory management (Oilpan). [2]

• Update Blink to be more multi-process aware and ready for out-of-process iframes. [3]

• Further modularize and homogenize Blink codebase.

• Reduce the time from when we ship a feature to when developers can use it.

• Make Blink and Chromium more accessible and welcoming to all contributors.

We are a very large project with many diverse ideas.  I look forward to hearing your thoughts! Hopefully this summary of some of our thinking will help inform your own planning for 2014.

1. https://docs.google.com/a/chromium.org/document/d/1ZkV1PpPsJJgdSZOA10Jh0VrThR6D_Q0XWv_2B9-0gGE/edit

2. https://docs.google.com/document/d/1y7_0ni0E_kxvrah-QtnreMlzCDKN3QP4BN1Aw7eSLfY/edit

3. http://www.chromium.org/developers/design-documents/site-isolation

[Kenneth Rohde Christiansen]

That is a great list of goals Eric! I am very excited.

I would also like to see it being a goal that we unify our graphics
pipelines, such that we can have impl-side rendering, pinch zoom
support enabled on all our platforms. Without that it is impossible to
ship features like CSS Device Adaptation (@viewport rule) on all
platforms at the same time, which can lead to it being very hard to
enable on desktop later (for example it is quite difficult to enable
viewport meta on desktop right now as many desktop sites actually
define it and expects it to be ignored). As more or our work are
geared toward mobile, this might even become more relevant to not
create a bigger divide between desktop and mobile.

I would also like to see if my co-editors and I can finalize the
Manifest spec (http://w3c.github.io/manifest/) and add some support
for that. Comments are very welcome and feel free to file issues here:
https://github.com/w3c/manifest/issues

Kenneth

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



--
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone +45 4294 9458 ﹆﹆﹆

[Alexandre Elias]

On Fri, Jan 10, 2014 at 1:53 PM, Kenneth Rohde Christiansen <kenneth.ch...@gmail.com> wrote:

That is a great list of goals Eric! I am very excited.

I would also like to see it being a goal that we unify our graphics
pipelines, such that we can have impl-side rendering, pinch zoom
support enabled on all our platforms. Without that it is impossible to
ship features like CSS Device Adaptation (@viewport rule) on all
platforms at the same time, which can lead to it being very hard to
enable on desktop later (for example it is quite difficult to enable
viewport meta on desktop right now as many desktop sites actually
define it and expects it to be ignored). As more or our work are
geared toward mobile, this might even become more relevant to not
create a bigger divide between desktop and mobile.

Agreed completely, we are all feeling the pain of the current platform divergence.  The areas you mentioned happen to not fall under the umbrella of Blink-team, but shipping impl-side painting on all platforms is on the list of high-priority goals for graphics-team (graphics-dev@), and pinch zoom on desktop for input-team (input-dev@).  We hope to have made progress on both those areas by mid-2014.

[Marshall Greenblatt]

Thanks for sending this Eric :) As someone who occasionally wanders into the CSS or FrameLoader code (and promptly gets lost) I would love to see a continued push to better document and demystify these complex state machines.

[Paweł Hajdan, Jr.]

On Fri, Jan 10, 2014 at 1:32 PM, Eric Seidel <ese...@chromium.org> wrote:

• Merge Blink repository into Chromium without loss of history.

Looking forward to that. Looks like it depends on migrating Chromium repository to git, right?

 

• Add safer (garbage collected) memory management (Oilpan). [2]

• Update Blink to be more multi-process aware and ready for out-of-process iframes. [3]

All of these are very exciting even though I don't develop in Blink. :)

• Reduce the time from when we ship a feature to when developers can use it.

Interesting. Does it mean some changes to our current approx. six weeks release cycle?

 

• Make Blink and Chromium more accessible and welcoming to all contributors.

Sounds good. Are there some specific changes you have in mind? Maybe I could help somehow, as it's also very important for me.

Paweł

[Nico Weber]

On Mon, Jan 13, 2014 at 11:34 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

On Fri, Jan 10, 2014 at 1:32 PM, Eric Seidel <ese...@chromium.org> wrote:

• Merge Blink repository into Chromium without loss of history.

Looking forward to that. Looks like it depends on migrating Chromium repository to git, right?

Not necessarily. https://docs.google.com/a/chromium.org/document/d/1QDkMgQB1BuQixXHYNrcMRRJ--EdlaCKvie9hdD2qR90/edit discussed several options, not all of them depend on this.

[erodrigu...@gmail.com]

The JQuery syntax should integrate Blink. All functions $() should run natively

[meni...@gmail.com]

First, I apologize if this is inappropriate here.

Google, please don't be like Microsoft, 2003. Back then Microsoft won the browser war and disbanded the IE team to work on more promising technologies (e.g. dotnet...). Little did they know how resilient the web is. "Microsoft was blind-sided by the web a second time" - Douglas Crockford

I have a similar feeling now, with some key people off the chrome team, and put to work on Dart. 

Right now on my humble laptop, just hovering the mouse cursor over the chrome canary icon, I can hear the fans go: "no, not again".

This is not good.

All the best, love you :-)

[anewpag...@gmail.com]

Amazing list, but I'd like to pile something big on top:

Garbage collection is a front-and-center issue for game development, and there really doesn't appear to be a great way to completely avoid having the performance rug pulled out from under you. Those drastic frame drops every 30 seconds or so affect even the most optimized game engines.

I know the V8 folks are reluctant to go in for AOT compiling, so I won't even broach the issue. Perhaps we gamedevs really do need an ulterior path. It is a somewhat niche use-case, but the problem is pervasive within that niche.

[Adam Barth]

If you have a test case that has trouble in garbage collection, please file a bug at http://crbug.com/new and CC me.  Generally speaking, we haven't seen many GC-related problems since we implemented the incremental collector, but that doesn't mean it isn't a problem---just that we don't have good test cases to work on.

Thanks,

Adam

[tcp...@gmail.com]

So google thought it would be nice to disable text wrapping / reflow in kitkat, a feature that's good enough for notepad, IE, firefox and just about every text displaying app ever.

Apparently it's now working (broken) as intended.

For more info and some pics see http://code.google.com/p/android/issues/detail?id=62378

[Nico Weber]

Hello,

This kind of post is wildly inappropriate for this mailing list.

Nico

 

[Adam Barth]

It's not appropriate to use this thread to advocate for fixing a particular bug.  Please take such discussion elsewhere.

Adam

On Mon, Jan 13, 2014 at 6:46 PM, <tcp...@gmail.com> wrote:

[tcp...@gmail.com]

You wouldn't want a little thing like actually being able to read a paragraph in a web page without having to scroll left/right to interfere with core performance metrics.

All I'm suggesting is beware of losing core functionality/useability in order to render a few milliseconds quicker

[shubhams...@gmail.com]

Well, Good that Chrome wants to develop, but as of now need option to disable images..

[Peter Kasting]

On Tue, Jan 14, 2014 at 6:27 PM, <shubhams...@gmail.com> wrote:

Well, Good that Chrome wants to develop, but as of now need option to disable images..

We've had that for years.  chrome://settings/content , change Images to "Do not show any images".

May I kindly suggest that external folks try and only comment in this thread with big-picture goals?  This is not an appropriate time to highlight every personal pet-peeve bug or isolated feature request.

PK

[Eric Seidel]

On Mon, Jan 13, 2014 at 11:34 AM, Paweł Hajdan, Jr. <phajd...@chromium.org> wrote:

On Fri, Jan 10, 2014 at 1:32 PM, Eric Seidel <ese...@chromium.org> wrote:

• Merge Blink repository into Chromium without loss of history.

Looking forward to that. Looks like it depends on migrating Chromium repository to git, right?

Thankfully that is no longer the case.  We have a plan to land in SVN and at the same time merge into Git.  SVN checkouts will not have Blink history, but those using Git already will have local history (going back to r1).

 

• Reduce the time from when we ship a feature to when developers can use it.

Interesting. Does it mean some changes to our current approx. six weeks release cycle?

In a world of perfectly tested code, we would release good changes to users immediately after checking them in.  Right now, a perfect code change takes on average 15 weeks between when we check it in and when users see it.  6 weeks in dev + 6 weeks in beta on avg of 3 weeks until next dev branch.  This is completely insane compared with how often modern web applications ship changes to their users.

Unfortunately we don't have perfectly tested code and so we use our release branches to attempt to mitigate the risk of shipping disruptive changes to users.  We'd need to continue to lower both our disruption risk as well as the time-from-commit-to-ship.  Suggestions most welcome!

 

• Make Blink and Chromium more accessible and welcoming to all contributors.

Sounds good. Are there some specific changes you have in mind? Maybe I could help somehow, as it's also very important for me.

I'd like us to think about at last:

- An easier to navigate Chromium.org (I often get lost trying to find the docs I want).

- Much easier-to-get-working compile setup ('fetch' has helped a lot, but webkit.org still does this *much* better).

- Better documentation of our code, goals, policies, etc.

- More consistent x-platform development experience (gyp and ninja help, but even something simple like getting a symboled build is different between OSes!)

- Simpler tools with fewer options. Wrappers for common complicated tasks.  (Building for Android needs a ton of help here.)

- Find ways to promote contributions to Chromium other than through code. (site design, packaging, porting, marketing, triage, community management, etc.)

- Find ways to attract a more diverse set of contributors (languages, regions, gender).  If we want to successfully serve as wide an audience as we do, we need better representation from that audience in our contributor base!

I think we should look around at other successful open source projects and see how we can be as or more welcoming.  I think there are many individuals interested in improving Chromium/Blink project accessibility but not necessarily an organized effort to rally behind.

Many of the core contributors are likely very blind to what it's like to not work at Google and have forgotten how difficult it might have been to get started on Chromium since they did it so many years ago (or with the hand-holding of their office mate).  We're likely going to need to depend on contributors from the wider open source project to provide an outside perspective on some of our accessibility issues.

Paweł

[Victor Costan]

Here are some comments from the perspective of a new contributor. I
hope they're helpful.

Victor

On Wed, Jan 15, 2014 at 3:18 AM, Eric Seidel <ese...@chromium.org> wrote:
> I'd like us to think about at last:
> - An easier to navigate Chromium.org (I often get lost trying to find the
> docs I want).
> - Much easier-to-get-working compile setup ('fetch' has helped a lot, but
> webkit.org still does this *much* better).

I think the first goal would help the second one a lot.

For example, compare these two guides.
Chromium: https://code.google.com/p/chromium/wiki/LinuxBuildInstructions
My notes: http://pwnall.herokuapp.com/blog/2013/10/24/build-your-own-chromium/

The official guide (linked from http://www.chromium.org/Home as "Build
Chromium on...") requires following other pages, so I had to go back
and forth, and I tried to read all the linked documents, to see what
applies to me and what doesn't.

My notes are a linear list of steps that hopefully represent the
recommended defaults, and have links for special situations. I think
this format is easier to follow, so I'm bringing it up. (I'll never
know for sure, I wrote my notes so I'm biased)

> - Better documentation of our code, goals, policies, etc.

There is a gap in the process documentation. "How to become a
committer" [1] seems to assume a @chromium.org address. However, by
browsing the other pages, the only way to get that seems to be
triaging bugs [2].

[1] http://dev.chromium.org/getting-involved/become-a-committer
[2] http://dev.chromium.org/getting-involved/get-bug-editing-privileges

> - Find ways to attract a more diverse set of contributors (languages,
> regions, gender). If we want to successfully serve as wide an audience as
> we do, we need better representation from that audience in our contributor
> base!

Hacking on Chromium requires pretty powerful computers (for building)
and a good Internet connection for downloading the repository. Some of
this can be worked around by fixing the guides. If the guides are
accurate, there's less trial-and-error required. Two other things that
I think would help are being upfront about the requirements (you'll
need ~1-2 days to checkout and build), and pointing out the steps that
will take a long time ("fetch blink" and "ninja -C ..."), so people
know when to do something else.

Another issue where WebKit does better is try server access. I think
that I could use EWS on my first patch, whereas it took a non-trivial
amount of effort to get try server access. This really helps a lot,
because getting a Windows build set up (or a Linux build, if you're on
Windows) has a very non-trivial cost in terms of time and
computational resources (cpu, ram, disk, bandwidth).

By comparison, getting edit access to www.chromestatus.com was rather
painless, and I think I still had to prove that I'm a real person with
good intentions.

Last on contributions, I think neither WebKit nor Blink are
capitalizing on layout tests as much as we could. In an ideal world,
Web developers would be able to provide layout tests when filing bugs,
and Blink developers would be able to use the try infrastructure and
confirm that they're valid, all from a Web interface, without touching
a checkout. An easy way to get going on this could be publishing a
template like http://jsbin.com/eVoWIDiC/1/edit, along with some good
examples.

I hope this helps,
Victor

[Lorenzo Stoakes]

On 15 January 2014 20:18, Victor Costan <cos...@gmail.com> wrote:

Hacking on Chromium requires pretty powerful computers (for building)
and a good Internet connection for downloading the repository. Some of
this can be worked around by fixing the guides. If the guides are
accurate, there's less trial-and-error required. Two other things that
I think would help are being upfront about the requirements (you'll
need ~1-2 days to checkout and build), and pointing out the steps that
will take a long time ("fetch blink" and "ninja -C ..."), so people
know when to do something else.

I suspect this varies a lot, my macbook pro manages a build in 1-1.5hrs from scratch, not sure what the fetch time would be (not done this from scratch for a while), so I guess it'd be hard to pinpoint exactly how long to say. Perhaps worth saying 'this is going to take a while, grab a coffee'. I swear I saw this on one of the wiki pages but a quick glance at the ninja mac build page doesn't have this there.

What I'd love, and it may be unrealistic, but it'd be awesome to have access to a build cluster. Perhaps access could be granted after a few commits to show seriousness? This is probably a pipe dream though ;-)

 

--

Lorenzo Stoakes
http:/ljs.io

[Elliott Sprehn]

On Wed, Jan 15, 2014 at 12:18 PM, Victor Costan <cos...@gmail.com> wrote:

...

Last on contributions, I think neither WebKit nor Blink are
capitalizing on layout tests as much as we could. In an ideal world,
Web developers would be able to provide layout tests when filing bugs,
and Blink developers would be able to use the try infrastructure and
confirm that they're valid, all from a Web interface, without touching
a checkout. An easy way to get going on this could be publishing a
template like http://jsbin.com/eVoWIDiC/1/edit, along with some good
examples.

I've been advocating for this for a long time. If you want to build a jsfiddle like app that files a bug to crbug.com and attaches the test case that'd be amazing!

- E 

[Dirk Pranke]

Hi Victor, 

Thanks for the feedback!

On Wed, Jan 15, 2014 at 12:18 PM, Victor Costan <cos...@gmail.com> wrote:

Here are some comments from the perspective of a new contributor. I
hope they're helpful.

    Victor

On Wed, Jan 15, 2014 at 3:18 AM, Eric Seidel <ese...@chromium.org> wrote:
> I'd like us to think about at last:
> - An easier to navigate Chromium.org (I often get lost trying to find the
> docs I want).
> - Much easier-to-get-working compile setup ('fetch' has helped a lot, but
> webkit.org still does this *much* better).

I think the first goal would help the second one a lot. 

For example, compare these two guides.
Chromium: https://code.google.com/p/chromium/wiki/LinuxBuildInstructions
My notes: http://pwnall.herokuapp.com/blog/2013/10/24/build-your-own-chromium/

The official guide (linked from http://www.chromium.org/Home as "Build
Chromium on...") requires following other pages, so I had to go back
and forth, and I tried to read all the linked documents, to see what
applies to me and what doesn't.

My notes are a linear list of steps that hopefully represent the
recommended defaults, and have links for special situations. I think
this format is easier to follow, so I'm bringing it up. (I'll never
know for sure, I wrote my notes so I'm biased)

Yeah, it's certainly easier to follow things when everything is on one page. A good editorial pass over the whole site would help identify such areas for improvement.

 

> - Better documentation of our code, goals, policies, etc.

There is a gap in the process documentation. "How to become a
committer" [1] seems to assume a @chromium.org address. However, by
browsing the other pages, the only way to get that seems to be
triaging bugs [2].

[1] http://dev.chromium.org/getting-involved/become-a-committer
[2] http://dev.chromium.org/getting-involved/get-bug-editing-privileges

Hm. Certainly, having an @chromium.org address isn't required, though we do still have a few bugs in the tooling that make something more difficult if you're not using one. I'll take a look at that page and update it.

 

> - Find ways to attract a more diverse set of contributors (languages,
> regions, gender).  If we want to successfully serve as wide an audience as
> we do, we need better representation from that audience in our contributor
> base!

Hacking on Chromium requires pretty powerful computers (for building)
and a good Internet connection for downloading the repository. Some of
this can be worked around by fixing the guides. If the guides are
accurate, there's less trial-and-error required. Two other things that
I think would help are being upfront about the requirements (you'll
need ~1-2 days to checkout and build), and pointing out the steps that
will take a long time ("fetch blink" and "ninja -C ..."), so people
know when to do something else.

Yup.

 

Another issue where WebKit does better is try server access. I think
that I could use EWS on my first patch, whereas it took a non-trivial
amount of effort to get try server access. This really helps a lot,
because getting a Windows build set up (or a Linux build, if you're on
Windows) has a very non-trivial cost in terms of time and
computational resources (cpu, ram, disk, bandwidth).

Yup. We're not likely at this time to make it quite as painless as it was for WebKit, unfortunately; we're just a little more paranoid.

-- Dirk

[Arunprasad Rajkumar]

It would be great to have a Blink as an embedable library (with content APIs as an entry point). 

[Victor Costan]

On Fri, Jan 17, 2014 at 12:39 AM, Arunprasad Rajkumar
<ararun...@gmail.com> wrote:
> It would be great to have a Blink as an embedable library (with content APIs
> as an entry point).

Take a look at CEF. It might be what you want.
https://code.google.com/p/chromiumembedded/

I haven't used it myself, but Adobe is using it in Brackets, so it can
work. Also, Brackets is MIT-licensed, so you can borrow / steal their
integration code.
http://brackets.io/

[kevin...@gmail.com]

This sounds great.

Ideally I would like to write mobile apps - especially for Android tablets - but with Web/Blink technologies. Apps that should not be distinguishable from 'native' in terms of touch responsiveness and animation smoothness. (The code twice deal - Java for Android and Ecmascript for web - is particularly annoying on tablets).

I'm focused on the new stuff: CSS Grid/Web Animations/Web Components/Touch Events/Emcascript6&7. Call it Web 3.0 - the most significant advance since the late 90's with Web 2.0 (dhtml/ajax).

If a developer made a commitment to code to a sane modern subset of 'Web 3.0', via say a META tag, could they get fast and fluid performance on a Android tablet. This subset would not have 'childNodes' style imperative updates of the dom. All async/reactive with a sane subset of ES6/7 (no ASI, global object, arguments,in etc).

Kevin

[Victor Costan]

Ah, mobile.

I recently learned about this project. It might do what you want.
https://crosswalk-project.org/

Also, if you can afford to target Android 4.4, WebView is powered by
Chrome 30's Blink and WebView.

Hope this helps,
Victor

[Kevin Curtis]

Thanks - Crosswalk looks interesting. From its website:

"At the heart of Crosswalk is the Blink rendering and layout engine. This provides the same HTML5 features and capabilities expected in the modern web ecosystem."

What I'm interested in is whether the Blink engine - if the developer agrees to stick to modern emerging web standards which are more declarative/async/reactive -- can offer superior touch performance. For instance if an app is a CSS Grid containing Web Components (with shadow dom). Reflows/redraws reduced?

I'm hoping that Android 5.0 offers a way for web apps to have parity with Java apps. A kind of unification for Chrome/OS and Android. And if targetting the 'Good New Parts' of the Blink platform is the means - all too the good.

Kevin

[Nat Duca]

Kevin, if you have any web apps that are mobile-like that feel particularly janky, we'd love to know more. Feel free to send them my way off-thread.

[jlu...@chromium.org]

On Tuesday, January 21, 2014 11:21:14 PM UTC-5, Nat Duca wrote:

Kevin, if you have any web apps that are mobile-like that feel particularly janky, we'd love to know more. Feel free to send them my way off-thread.

I'd also like to hear OT about mobile problems/pain points (from Kevin or anyone else!) related to <video> and <audio>.

[tcp...@gmail.com]

http://www.androidpolice.com/2014/01/28/bug-watch-text-reflow-removed-from-webviews-in-kitkat-probably-not-coming-back/

[tcp...@gmail.com]

http://imageshack.com/a/img546/6007/0wbf.png

Seriously?

[Nico Weber]

tcpaulh: This isn't what this group is for.

On Wed, Jan 29, 2014 at 8:31 AM, <tcp...@gmail.com> wrote:

http://imageshack.com/a/img546/6007/0wbf.png

Seriously?

[tcp...@gmail.com]

Here's a brainstorming goal for you for 2014. Fix webview http://imageshack.com/a/img546/6007/0wbf.png

[sethk...@gmail.com]