Earlier quoted context omitted.
That has two problems: 1) A lot of flight tests can't be done without a large fraction of passengers on the plane. 2) It may make getting to the final end state faster (though maybe not), but it means you don't get any benefits until you make the switch. Doing things incrementally means you start seeing benefits much earlier. Classic throughput/latency tradeoff.
What's better to end up in the final end state later, or lose customers because your software is crashing and is harder to maintain because you're introducing totally new way to do stuff?
Transitioning Firefox's rendering engine from Gecko to Servo
171–180 of 219 posts
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#172Earlier quoted context omitted.
> Servo makes incredibly good use of the GPU. Too good, in fact: it won't run on any laptops that I own because their GPUs don't support a sufficient level of OpenGL. One great aspect of Firefox-with-Gecko is that you can throw it onto just about any machine with more than 512MB of RAM and it will provide bootstrap web access ( slow or otherwise ). That's going to be lost when everything is Servoised. I guess it's ba…
How old are your laptops? For ease of development, webrender2 is configured to compile with the latest OpenGl 4.x features. I believe there is a way to build it to target a lower OpenGl version. Edit: Correction, its currently targeted at OpenGl 3.2. There's an open issue for bringing it down to OpenGl 3.1 which is the version supported by integrated Sandybridge GPUs. Considering 40% of people running Intel are using…
Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller
OpenGL renderer string: Mesa DRI Intel(R) 965GM
Maximum OpenGL version for that chipset is 2.0, apparently, though I can't find a way to push it beyond 1.4 on Linux
I appreciate that six years old is ancient by SV standards but I would be interested to learn what proportion of Firefox users are on equally old hardware. I did try launching Servo with CPU rendering but it hung indefinitely.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#173I've seen this before: >> At some point in mid-2017, all new CSS will be built with Quantum plane parts, not Gecko. Going forward, it will be much easier and more enjoyable to implement new CSS properties. Which makes it easier for folks in the open source community to contribute. If you're not careful this can drag on for years with half the stuff done one way and half the new way - especially once you reach the poi…
Now I try to ensure we agree up front which issues will be blocking, and how much extra memory / CPU is acceptable, which features have to be kept, etc.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#174Earlier quoted context omitted.
A good way to force this along is to have a champion for the work, and an automated burndown metric that random devs can watch and influence. Mozilla is pretty good at the latter, cf. https://arewefastyet.com
Seems like Safari is doing better than everything else if I'm reading the charts right.
>Safari defaults to 64-bit machines and doesn't need to worry about 32-bit anymore. Big pieces of their engine is 64-bit only. As a result showing Safari on 32-bit machines would give incorrect results.
Maybe this has something to do with it?
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#175> And Firefox runs on Gecko. Which is old. Like really old. I think it's the oldest rendering engine still in wide use. Gecko may be oldest, but not with wide margin: KHTML (the origin of webkit and blink) was started in 1998, only a year after Gecko. Of course, probably not much (if any?) of the original KHTML source is still present in webkit, and because of the nature of open source development, there is blurry li…
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#176Earlier quoted context omitted.
Ironically Mozilla is the best counter-example to that Joel on Software article. The article specifically mentions that Netscape shouldn't try and re-write their browser. But if they hadn't done that, we wouldn't have Firefox. We'd still have an incremental improvement over Netscape 4.7. For those who can't remember Netscape 4.7, let me remind you, it wasn't very good at the end. If they hadn't rewritten it, causing…
The complete rewrite wasn't initially too good either. It took them years to bring it on par with Netscape 4.7, warts and all. I've been in a talk of a mozilla developer like a decade or more ago, shortly after they had released the rewrite. His comment on starting a project like that from scratch: "don't". What they intend to do (slowly and gradually transition to Servo) seems consistent with an organization that ha…
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#177I'm on this rust hype train for a long time. This move by mozilla is probably going to be the biggest success story that might give rust a lot of attention. I hope the new engine is fast as heck and uses less battery in all my devices. Please!
If performance is not competitive, it will not be much of a success story, but it will be more interesting to see how much better it will be in terms of security issues.
I don't think this will be a problem. One example...
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#178Earlier quoted context omitted.
Mozilla is really just another software company owned by a nonprofit. They have hundreds of millions in revenue and have been "profitable" in many/all years. But they are definitely much smaller than Google/Apple/MS and can't benefit from ecosystem lock-in effects.
Everything's comparative, of course. Mozilla isn't a solo dev's weekend project, but it's also not a top 10 most valuable company in the world, like all of its competitors are.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#179Working at a company where I occasionally create presentational sites, I often have to create and optimise animations that some designer thought would be so very radical and the two browsers that are extremely painful to support are usually Firefox and Internet Edge-splorer (pardon the pun).
I have animations that run at a smooth 60fps in Chrome and Safari effortlessly, quite often producing 1-2 FPS in Firefox. Their updates are quite weird too, between the last 3 updates, I've seen the project I was working on run bad enough that I had to fallback to the mobile-lite version on FF to running acceptably (30+ fps) to running like crap again.
And maybe we'll see 16 year old style rendering bugs get fixed finally, too? Please, pretty, please?
After ripping on it a bit, tho, I have to say: I'm looking forward to running Firefox again in the future, as much as I like Safari at the moment, it's closed source and I don't like being exposed to Apple's whims (especially lately), where if they decide to destroy by making it unusable I'm left out to dry and quite frankly Google Chrome just creeps me out now.
Re: Transitioning Firefox's rendering engine from Gecko to Servo
#180Earlier quoted context omitted.
I disagree. If they are able to deliver a browser that's much faster and consumes less battery, I believe that would be enough to make a lot of users change their browser. Maybe I'm wrong and I'm not a good example, but I the only add-ons that I have installed that I really care about is 1password (which is easy to live without, as I can use the stand-alone application) and HTTPS everywhere (which just means that I h…
AFAIK, about 40% of Firefox users don't have any add-ons.
Then there is the fact that every other browser has, or is in the process, dropped any notion of direct native add-on APIs and an increasing majority of actively developed add-ons for all browsers is now modern "Chrome-style" JS+HTML components.