311–320 of 326 posts
Earlier quoted context omitted.
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.
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…
Maybe because anyone who has used Safari knows that WebKit2's multiprocess architecture is worse in practice. As a full-time Safari user I can tell you that things have gotten markedly worse since it went multiprocess. Pages go white momentarily (not crash) all the time, and on top of that they also crash all the time. Additionally, I believe that unlike Chrome, Safari has ONE separate process for all the tabs, and t…
Earlier quoted context omitted.
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.
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)
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. The…
Actually, they "merely" leverage their platform by using CoreAnimation, making it GPU accelerated (and enabling pinch-to-zoom), while Chrome scrolling hits the CPU really hard.
Earlier quoted context omitted.
Open source monocultures can be pretty bad. Look at how Mir has jumpstarted Wayland interest and adoption after it has stagnated for a few years. Likewise, look at how GCC is now dramatically improving since Clang became competitive. Or look at how Firefox back in the good old days picked up the pace after Chrome(ium) happened.
Multiple efforts can increase competition or spread resources thin. We already have 3 major engines. Do we need a fourth? The Linux Kernel combines all efforts in a single thriving project, while we have multiple desktop distributions struggling to get a single digit percentage of the market.
Though considering how they fund Mozilla in the first place, if they wanted Gecko, they would just buy Mozilla. They keep the lights on anyway.
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)
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…
Earlier quoted context omitted.
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…
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…
I always believed (hoped) you guys would never be corrupted and do the right thing for the world and not be swayed by organizational affinities / commercial gains.
You have a greater responsibility than to your company or country to keep the web open.
Think on that before you have a further public 'kiddy debate' on she said / he said and throwing the rattle out of the pram.
Disappointed.
Earlier quoted context omitted.
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…
?? If there's practical reasons, then you need to explain why the practical reasons are not strong enough to warrant this? Just look at what was accomplished by this, they were able to delete over 8 million lines of code that was boilerplate.
> And others argue why it will.
Then, it's still not a strong argument against this.
> [snip]
What exactly are you advocating? Look at all the chromium design docs they wrote, and all the code reviews are in the open. If anything, the WebKit reviews are much harder to look through. The rest of your rant is irrelevant. Do you want them to spoon-feed you everything Chromium/Blink engineers do?
You can argue all day if you want, but what exactly are you proposing the alternative is? How does not forking help in any of those?