8 ms·
Mozilla's Servo Engine Now Capable of Rendering GitHub
- kbrosnan 11y agoDirect links to the tweets that prompted this article. Github - https://twitter.com/pcwalton/status/633411771617832961 https://twitter.com/pcwalton/status/633411771617832961 Ars - https://twitter.com/pcwalton/status/631961638304804864 https://twitter.com/pcwalton/status/631961638304804864
- haberman 11y agoReally curious to hear more explanation of this comment from Patrick: "Printing is pretty incompatible with parallelism though." Is he saying that Servo as a parallel engine won't be able to handle printing?
- pjmlp 11y agoMost likely due to the way printing APIs work across OSes.
- dubcanada 11y agoI'm assuming what they would do is render the website using multi threading and then generate a PDF or something and print that. But basically printing APIs are not multithreaded across all OS's
- smt88 11y agoIt's likely possible to work around that limitation. For example, Servo could render to a binary image and then send that to the printer.
- jahewson 11y agoUsing a raster image is a recepie for slowness, especially at common printer resolutions of 300dpi+. It also breaks "Save as PDF" from the print dialog. Far better to communicate with the print driver using GDI, PostScript, PCL, PDF, etc. using vector graphics and embedded fonts.
- pcwalton 11y agoThat's not the problem. We could easily run our parallel screen layout and then just use Skia (or the local system)'s PDF backend. The trouble is that this doesn't implement the printing spec. As Simon mentioned above, the problem is the various CSS rules that control pagination.
- gsnedders 11y agoThat's not the limitation — the limitation is the effects of pagination on layout, especially given control of where page breaks occur and restrictions on widows and orphans.
- leni536 11y agoWhat kind of parallelism is expected here? Is it about that you can't render layout to postscript or PDF well parallelized?
- SimonSapin 11y agoPatrick refers to parallel layout here: in a text with many paragraphs for example, the contents of each paragraph can be laid out in parallel with other paragraphs. Then you only need to sum up the heights of earlier paragraphs to find the vertical position of each. When printing though, you don’t know where to start page 10 until you’ve done the layout of earlier pages. There may still be some parallelism opportunity, but less than on screen.
- leeoniya 11y agonice. i wish the blog was updated more frequently - http://blog.servo.org/ http://blog.servo.org/
- Manishearth 11y agoThis is entirely my fault. I was the one writing This Week In Servo blog posts, and I had a rather busy internship over the summer which didn't leave me much time to write the blog posts. And now I have a rather busy semester -- I probably could carve time out to start writing again, but right now I'm too swamped to do it. I'm glad you enjoyed the posts, though! Following http://twitter.com/ServoDev http://twitter.com/ServoDev can keep you up to date for now.
- jxn 11y agoThanks for the write-ups that you did. It's so much more tempting to contribute to a project when there are active public summaries of work being done. Sometimes, I admit, I don't even bother submitting my pull requests on projects with 50 unmerged PRs and no activity. When I see evidence of a progress and organization like those blog posts, it makes me want to contribute even if I don't necessarily have a personal itch to scratch. I'd love to see more posts soon, if you or someone else ever gets the time*!
- artificial 11y agoI also enjoyed reading this week in Rust! Thanks to your efforts I've found many great projects, it's inspiring.
- grayrest 11y agoIf you're interested in checking out the progress, the build process[0] is really easy. Here's the current page: http://i.imgur.com/NmRNaRz.png http://i.imgur.com/NmRNaRz.png If you want to poke around more, servo shell[1] lets you switch starting pages without having to re-run from the command line. [0] https://github.com/servo/servo https://github.com/servo/servo [1] https://github.com/glennw/servo-shell https://github.com/glennw/servo-shell
- deleted 11y ago[deleted]
- Coding_Cat 11y agoHuh, the image seems to have a different colour than HN has on my browser (Firefox). I wonder what causes that, usually GPU colour corrections don't show up in screen-shots. Compression?
- Danieru 11y agoUsers can set their own color on HN. For example my account has the header in my favorite shade of green.
- hadrien01 11y agoHow? I can't see it in the options
- barkingcat 11y agoIn your profile settings, it's the "topcolor" setting.
- fernandotakai 11y agoyou also need a specific number of points.
- 11y ago
- deleted 11y ago[deleted]
- smt88 11y agoThe downvotes are because there was no content in your comment. "So much win!" can be expressed by clicking the upvote arrow instead.
- tbrock 11y agoIs multithreaded rendering really the next big browser breakthrough? If so, are Google and Apple also working on similar projects?
- bobajeff 11y agoI remember Brendan Eich saying that you can bet on it. But he included Microsoft in that statement and given all the work on forking Trident into EdgeHTML I'm pretty sure they weren't. Apple and Google could very well have secret projects going on for such a thing though.
- qznc 11y agoI don't think it will feel like a breakthrough. On the desktop the network is the bottleneck, not the rendering. However, it might save energy on mobile multicore devices. That is nice, because on my smart phone the browser really drains the battery.
- pcwalton 11y ago> On the desktop the network is the bottleneck, not the rendering. That's pretty oversimplified. For lots of workloads—e.g. interacting with widgets on the page, composing emails/etc, scrolling, opening pop-out menus, interacting with Google Maps—the rendering (broadly speaking) is the bottleneck. In fact, I'm of the opinion that improving layout and graphics performance is the single biggest thing we can do to make Web apps not feel slow compared to their native counterparts. People still (often quite rightly) feel that the Web is slower than native (however "native" is defined). The difference is unlikely to be network-related, and it's unlikely to be JavaScript either for most apps—JS performance may not be at C++-level yet (though asm.js will get there in time), but it's certainly on par with Objective-C and Java/Dalvik. The problem is mostly styling, layout, and graphics in my view: how to get from the DOM to rendered pixels as quickly as possible. Those are, not coincidentally, what Servo has focused on.
- bobajeff 11y agoSo does that mean the experiment to use it in B2G has a more utilitarian purpose than just stretching the limits of the engine?
- seertaak 11y agoI have to say, as a C++ developer, I'm really impressed with Rust's progress in the last year. Creating a browser rendering engine is a complicated task -- it's a very strong proof that the language is practical. Rust also seems to have a friendly, engaging community, and leaders (e.g. pcwalton) that are fair-minded and that invite and inform rather than scare away. The docs are nicely presented and informative. The language feels fresh and modern. The build and library discovery story is 10x better than what C++ offers. In short, there's a lot to make you want to move over. Still, I a) have a ~90K LOC code base in C++/Obj-C that I'm not going to abandon any time soon, and b) after having gotten burned (in Haskell) by the "more purity or strictness (in the conventional, not evaluation, sense) is always better" argument, I'm waiting to be convinced that having a more picky compiler actually helps rather than getting in the way. As mentioned above, projects like this certainly make one more confident that it does help.
- steveklabnik 11y agoAbandoning ~90k LOC certainly seems like a bad idea, but since Rust can basically pretend to be C, you could just peel off a certain part of your app, and have a hybrid codebase. Your C++ would just link to the Rust like any other C library. This is the approach Firefox is taking.
- k__ 11y agoFirefox' C parts are getting incrementally rewritten in Rust?
- steveklabnik 11y agoSlowly. There's two patches right now: using Rust for URL parsing, and an MP4 parser. They're not being built by default, but you can set an option at compile time to use them. There's some more work to be done before they'll start appearing in regular builds. See here for more: * https://developer.mozilla.org/en-US/Firefox/Building_Firefox_with_Rust_code * https://bugzilla.mozilla.org/show_bug.cgi?id=1175322 * https://bugzilla.mozilla.org/show_bug.cgi?id=1151899 (and Firefox is mostly C++, not C)
- Scarbutt 11y agoMozilla really needs to step up its game and start innovating, a technically "superior" browser won't make it gain market share against Google, Microsoft and Apple, these three have powerful platforms to promote their browsers, what does Mozilla have? Firefox's usage is declining every day at a fast pace. I'm amazed to see how much average Joe users have Chrome installed with no help from anyone. Edit: Want to add that I wasn't taking a stab a Servo, which is a truly awesome project on its own no matter what's going with Mozilla.
- pcwalton 11y agoThis is a truly bizarre comment. Can you elaborate as to how Servo is not "innovating"?
- Scarbutt 11y agoWith the "innovating" part I was talking about Mozilla in general, not Servo. Servo is innovating in the web browser space, no doubt about that, but will that really be enough for Mozilla to compete with others browsers which have big platforms supporting them? I'm talking from a business angle here.
- magicalist 11y agoIt's important to remember that Servo is just a research project at this point. A lot of hopes are behind it for the future, but in terms of engineering resources it's not been any sort of significant drain on Mozilla's other efforts.
- pcwalton 11y agoThe only charitable interpretations of this comment I can figure out are either "Mozilla shouldn't bother improving its core technology because it's doomed anyway" or "Mozilla should build a 'native' OS stack to push its browser", which are gratuitous negativity and off-topic/silly, respectively.
- bobajeff 11y agoMozilla has tried to enter the OS space with Firefox OS. Unfortunately, that hasn't worked out so well for them so far. Entering a mature market with a new product often winds up a fruitless effort. I think they'll have a better shot with new categories like Smart Watches, Smart Mini MP3 Players and those Smart Flip Phones/Sliders. Android is having major issues entering those categories for quite some time so that leaves a good opening for competition. Another thing they can do is to build their own phone. Make it the best phone that they possibly can and support it for 5-10 years. With the only revisions making it smaller and cheaper but otherwise the same (ie. same architecture but miniaturized). Even if during those 5-10 years it's not seen uptake Mozilla will have built up a unmatched reputation for supporting their devices. So when the successor is announced...
- pcwalton 11y agoAlso see Ars Technica rendered in Servo: https://twitter.com/pcwalton/status/631961638304804864 https://twitter.com/pcwalton/status/631961638304804864 I've been working on knocking down layout bugs that affect the most popular sites lately. Please feel free to try it out and file GitHub issues, especially if you can minimize test cases! You're definitely likely to see various degrees of brokenness on most sites, but the core CSS 2.1/CSS3 layout is pretty solid at this point; there's just a long tail of bugs and corner cases we've got to nail down. This is where finding and isolating the bugs that break the major Web sites is important!
- andy_ppp 11y agoInteresting, as a web developer I really really want Servo to become a big success. I wonder at what point do Mozilla think I should start having a once over in Servo before putting my sites on the web? Why not, I'll start doing this as it can't do any harm and create some test cases should I find some weirdness. It's really easy to build a copy of servo after all: https://github.com/servo/servo The instructions there generally just work.
- pcwalton 11y agoDon't contort your Web sites to work around brokenness in Servo; just file bugs. Rendering bugs are our bugs, not yours :)
- Stormcaller 11y agoI wonder if there was an idea of a "strict mode" at any point? When making sure every site works surely you guys will have to render invalid code "correctly", I assume. For example I am willing to develop in your browser if it meant I wouldn't broke some rules and the browser would care about that. Of course html validators exist and browsers display invalid css in their inspectors but I am asking for something like that would expect valid code. throw an error in my face if I didn't close a html tag or used an invalid css value, at any point. Like if a javascript code resulted in my page getting invalid layout then browser could yell at me that causes an invalid layout. Maybe even a small performance improvement if my code conformed to every layout rule.