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.
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
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.
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.
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,MarshallAdamTo unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
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.
No plans to change. If we wanted, we could move some parts of the code to libraries to change the licensing.
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
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.