Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blink: A rendering engine for the Chromium project

blog.chromium.org

Post reply on HN
Print view View original

301–310 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#301

Post by simonster »

smackfu wrote: post #286
nnethercote wrote: post #266

Earlier quoted context omitted.

http://www.ohloh.net/p/WebKit claims that WebKit is 4,825,108 LOC. http://www.ohloh.net/p/mozilla claims that Mozilla is 11,614,049 lines of code. Hmm. Not sure what to make of that, but the "we're removing 4.5 MLOC" claim still sounds ridiculous.

Seems a very odd part of the announcement to question. Why wouldn't they know the real number?

I think the implication is that most of the code they are removing is not actually code, but boilerplate/machine-generated build scripts/etc. Still, the number of LOC involved has little bearing on whether or not splitting from WebKit is a good idea.

Re: Blink: A rendering engine for the Chromium project

#302

Post by kyrias »

justinschuh wrote: post #288
kyrias wrote: post #267

Earlier quoted context omitted.

> So, I must be misunderstanding you, because it seems like you're suggesting that > you expected Chrome engineers to simply do all the work. Nah, you're not misunderstanding, Apple/WebKit has a track record of doing this.

I expect that's not the case, and I'm just missing the point othermaciej is trying to make.

Well it doesn't really matter if you expect it or not, the fact still stands that they do.

Re: Blink: A rendering engine for the Chromium project

#303

Post by binarycrusader »

makomk wrote: post #118
macrael wrote: post #112

So, I'm pretty sure this is a correct history: 1. Google builds a new process architecture into Chrome as a product differentiator. (It was a major part of Chrome's initial marketing) 2. WebKit 2 is built (mostly by Apple?) to bake the same type of architecture straight into the core framework -- anyone using WebKit can use it and get the same security/stability benefits.[1] 3. Google says that the pain in maintainin…

Apple's current commit approval policies appear to be fairly hostile to non-Apple developers and users of WebKit, and especially to non-Apple users of WebKit2. They now reserve the right to break builds on non-Apple platforms randomly and delay patches to fix them, amongst other things.

Google is no different policy-wise for the chromium project. Neither of them are saints here.

Re: Blink: A rendering engine for the Chromium project

#304

Post by Shooti »

othermaciej wrote: post #298
justinschuh wrote: post #225

Earlier quoted context omitted.

>Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks. The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Mem…

My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting. I regret that this thread has turned into such a back-and-forth. It's not my goal to detract from the Blink announcement. I feel like it would be rude to leave you hanging on mid-thread. Howev…

A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task.

In light of this, your initial "if Google had only upstreamed their multiprocess support...we almost surely" and reiterations on this point within the thread do seem a bit like PR sleight of hand, since out of context it implies willingness to do so was the only issue on their part.

Re: Blink: A rendering engine for the Chromium project

#305

Post by bazaarsoft »

othermaciej wrote: post #183
mikewest wrote: post #126

Earlier quoted context omitted.

It's a complex question. To be stunningly reductive: the architectures are simply quite different. We hook into the network stack in different places, we have different sandbox models and constraints (Win XP for instance), etc. Also note that the timing is fairly important: Chromium was quite far along with our implementation when WebKit2 was announced, and rather than iterating on the solution we'd proposed and run…

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute t…

Open always wins.

Re: Blink: A rendering engine for the Chromium project

#306

Post by jfoster »

dubcanada wrote: post #173
jfoster wrote: post #119

Earlier quoted context omitted.

That's an interesting way of looking at it. Apple no longer get a free ride. On the other hand, now that Firefox is using WebKit perhaps Mozilla just replaces Google there.

You do know that most of the WebKit code as it is is Apple's right? If anything it was Google who got a free ride.

Sorry I should've been clearer. I am aware of that, but since anyone can use the code, the most important thing for those using it is that what they have tired their product to is actively maintained. If they don't do the majority of the work to maintain it then I think of them as getting a free ride from whoever is actively maintaining it. I don't mean that as a negative, either. Every company gets free rides in some way or another. Web companies off those that pioneered the web, for example.

Re: Blink: A rendering engine for the Chromium project

#307

Post by justinschuh »

othermaciej wrote: post #298
justinschuh wrote: post #225

Earlier quoted context omitted.

>Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks. The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Mem…

My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting. I regret that this thread has turned into such a back-and-forth. It's not my goal to detract from the Blink announcement. I feel like it would be rude to leave you hanging on mid-thread. Howev…

Yeah, I didn't intend this to turn into a back and forth. I think we both had similar intentions, but from different perspectives and with different first-hand information that may not be well communicated. I agree that it's best to leave it be from here. I think both of us and our respective projects bear no ill will and desire the best for the Web as a whole, despite differences in how exactly to get there.

Re: Blink: A rendering engine for the Chromium project

#308

Post by othermaciej »

Shooti wrote: post #304
othermaciej wrote: post #298

Earlier quoted context omitted.

My interest in this thread was only to report on some history that I knew about personally, to correct what I thought was an incomplete version of events. I think a bunch of people found that information useful and interesting. I regret that this thread has turned into such a back-and-forth. It's not my goal to detract from the Blink announcement. I feel like it would be rude to leave you hanging on mid-thread. Howev…

A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A ( http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s ), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task. In light of this, your initial "if Google had only upstreamed their multiprocess support...we almo…

1) The answer wasn't "we'd like to do this but we're super busy right now, how about later" or "that's super complicated, will you guys put in a lot of the effort". It was a pretty direct no. We would have been willing to do much of the work.

2) My recollection is that we talked about it around a year after Chrome was released. Chrome Beta release date: September 2, 2008 Date of WebKit2 announcement: Thu Apr 8, 2010 (after 3) Does the reason for saying no affect whether our choice to make our own thing was reasonable?

Re: Blink: A rendering engine for the Chromium project

#309

Post by Camillo »

saebekassebil wrote: post #294
kalleboo wrote: post #213

Earlier quoted context omitted.

Safari is the only browser that has decent scrolling performance on a Retina MacBook. All the other browsers stutter really badly as soon as the page has any complexity with fixed elements (Facebook is a big one)

So true, this is actually one of the things that almost convinced me to switch to Safari. I'd miss the Developer Tools though..

But the developer tools are in Safari.

Re: Blink: A rendering engine for the Chromium project

#310

Post by danpeddle »

About enabling experimental features via flags - I hope there will be an option buried in there somewhere for curious people to "go nuts" and enable a large slew of functionality in one step, appropriately warned. I can see that being a pain, but much easier than having to go one by one on obscure features with a non-technical audience.

I love seeing what creative devs are doing out on the fringes, and having to dig around in flags every time something new gets added could potentially get pretty annoying. The benefit of vendor prefixes was this - if you were on a latest version, not just dev/canary channel, there was a lot which was turned on by default, even if theoretically it wasn't stable. That was actually quite a good driver of fresh technique and innovation, seeing this straight away, despite the major hassle of bloated CSS.

It's inspirational seeing people who maybe aren't totally technical being able to get their hands on very fresh stuff without having to completely hand hold them on every step required to get it going.

Really, a lot to be said on this topic, but just wanted to mention this as didn't see it discussed yet.

Post reply on HN