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

281–290 of 326 posts

Re: Blink: A rendering engine for the Chromium project

#281

Post by ferongr »

othermaciej wrote: post #204
Me1000 wrote: post #191

Earlier quoted context omitted.

I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.

If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions. To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & god…

>that would have been super rude. Don't you think?

As long as the license allows it and the maintainer is not burdened in any way, no?

Re: Blink: A rendering engine for the Chromium project

#282

Post by coldtea »

cromwellian wrote: post #237
coldtea wrote: post #146

Earlier quoted context omitted.

Yes. Announcing this especially today seems like a "fuck you" at Samsung. Downvotes? Anybody thinks that two companies that are in some heat over Android/Tizen et all, just coincided to release information about new rendering engines on the same day? As if rendering engines are announced every other day, right?

Did you ever consider that the launch date had been scheduled a long time ago?

How does that invalidate what I said?

The only requirement for "stealing thunder" is for one party to know in advance the scheduled date for the other party.

Re: Blink: A rendering engine for the Chromium project

#283

Post by S_A_P »

Shooti wrote: post #273
malandrew wrote: post #167

Earlier quoted context omitted.

The tab behavior in chrome is what does it for me too. In fact, you can have so many tabs that you can no longer open the last tabs (the tabs extend past the little full screen or switch user icon). I also think Safari has a much better solution for handling bookmarking when you have multiple tabs. Solve these two issues and I'd switch to Chrome in a second.

FWIW activating "Stacked tabs" in Chrome://flags resolves this by switching to the tablet implementation which doesn't shrink the tabs.

I went and looked at the "Stacked Tabs" flag and it appears to be Windows only.

From Chrome://Flags-

Stacked Tabs Windows Tabs never shrink, instead they stack on top of each other when there is not enough space. Sorry, this experiment is not available on your platform.

Re: Blink: A rendering engine for the Chromium project

#284

Post by coldtea »

jxi wrote: post #261
lawl wrote: post #259

Earlier quoted context omitted.

Well I just came across this: http://prng.net/blink-faq.html I think it shows (some of) the concerns really well. Not saying EEE is the strategy Google is trying to do here. But it's certainly a possibility and we should pay close attention IMO.

Wow, that is the most ridiculous thing I've ever read. Pretty sure it's a troll post trying to make frontpage with sensationalist bullshit. For example, he claims it's a political move, yet the official FAQ lists many practical reasons for the move. Also, he says it will fragment the web: half the comments in this very thread explains why it won't. Then he says it's not open source because it's hard to understand how…

>For example, he claims it's a political move, yet the official FAQ lists many practical reasons for the move.

So what? They couldn't make up excuses?

>Also, he says it will fragment the web: half the comments in this very thread explains why it won't.

And others argue why it will.

>Then he says it's not open source because it's hard to understand how an HTML parser works? wtf?

A complex multi-million line project representing 1000s of manyears of work, essentially needs dedicated full-time highly skilled engineers to be forked. It might be technically "open source", but it's not bazaar-style open source, the way something like a simpler program or web framework is.

Even a highly skilled C++ programmer has to spend months to understand the WebKit codebase, much less do any pervasive changes or take over the code. This kind of devotion cannot be sustained by unpaid volunteers. That makes it essentially un-forkable unless some other company can devote resources to it.

Highly complex codebases seldom progress much as community projects after the original company has abandoned the paid contributors (see the lackluster Gnome development the last 10 years, after all the late 199x early 200x backers backed down, Open/Libre Offices --haven't progressed much from 2000's SUN's offering--, etc). And those are the cool cases, others die completely or languish (e.g Hazel's Nautilus, or Evolution).

Re: Blink: A rendering engine for the Chromium project

#285

Post by smackfu »

kalleboo wrote: post #213
kevincennis wrote: post #133

Earlier quoted context omitted.

Sincerely curious: why are you still a full-time Safari user in light of all those complaints?

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)

That's a case where Apple has to optimize the heck out of Safari until it is workable on that particular new machine, otherwise it would get terrible reviews and hurt the overall brand.

Chrome doesn't have the same incentives to get that particular machine working well, especially since the next revision of the Retina Macbook probably won't even need special handling since it will surely have a more powerful GPU. They can just wait it out, similar to what happened with the iPad 3 vs iPad 4, where people had to optimize for the iPad 3 and then those optimizations were unneeded on the iPad 4.

Re: Blink: A rendering engine for the Chromium project

#286

Post by smackfu »

nnethercote wrote: post #266
dragonwriter wrote: post #234

Earlier quoted context omitted.

> Last time I measured (late 2012) the entire mozilla-central repository was 4.488 million lines of code. Mozilla isn't WebKit. > I don't believe that by simply streamlining things they'll be able to remove anything like 4.5 million lines. I suppose you could compare WebKit repos against Blink repos once the latter is live to see exactly what is cut, but I'm going to say the people working on the code that are the so…

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?

Re: Blink: A rendering engine for the Chromium project

#287

Post by smackfu »

slacka wrote: post #215

> "For example, we anticipate that we’ll be able to remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines" On my 2GB netbook, chrome has gone from my preferred browser to unusable due to the high memory footprint of recent builds. I wonder if this cleanup will help get the memory down to something reasonable like where it was up until Chrome 10 or so.

Doubt it. I think these were part of the project that weren't even distributed.

Re: Blink: A rendering engine for the Chromium project

#288

Post by justinschuh »

kyrias wrote: post #267
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…

> 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.

Re: Blink: A rendering engine for the Chromium project

#289

Post by dragonwriter »

nitrogen wrote: post #223
erichocean wrote: post #157

Earlier quoted context omitted.

and it gets fixed You had me until that. I've had legit, simple, reproducible bugs sit in browsers for years when they're on "new" features that aren't standardized, yet somehow, every other browser that implements the same feature doesn't have the bug. Browser vendors use the "not-standardized yet" claim to avoid fixing bugs, while still shipping those features, in my experience.

Indeed. Here's one example that's been open since Chrome 3: https://code.google.com/p/chromium/issues/detail?id=29502 Another issue with Chrome is that percentage widths are rounded or truncated to the nearest pixel, so creating three 33.3% divs won't fill 100% of the space. It makes a fluid grid difficult to create. I reported this one with the built-in bug reporter, so I don't have an issue link.

> Here's one example that's been open since Chrome 3

I'm not sure that pointing out a "known WebKit bug" (as stated in the linked issue) affecting Chrome for which the Chromium team has a patch that apparently hasn't been implemented upstream is the best example of a problem with the "post on the Chrome/Blink tracker and get the issue fixed" approach, given that that approach was offered as an approach to take to deal with issues arising after Chrome splits from WebKit specifically to stop being constrained by WebKit from making changes.

Post reply on HN