Re: [dev-servo] meeting notes (incremental layout)

On Tuesday 2014-07-08 13:46 +1200, Robert O'Callahan wrote: > > > > > >- jack: can we avoid width recalc when changing vertical height? > >pcwalton: that will break with vertical writing modes, among other > >things. not sure it's a good optimization. > > > > > I'm not sure what jack ha

Re: [dev-servo] meeting notes (COW DOM)

On 7/7/14 8:07 PM, Robert O'Callahan wrote: The pragmatist in me loves it :-). There's probably a principled way to implement ForgetSkippable in a way that's automatically checkable. Having said all that, I'm not necessarily advocating GC+CC for Servo. It is a hard and complex approach. I'm sti

Re: [dev-servo] Meeting notes (Q3)

On Mon, Jul 7, 2014 at 8:03 PM, Robert O'Callahan wrote: > > If you want to brainstom about getting to absurdly low memory targets like > 32MB, I suggest talking to Nick Nethercote. This is where he lives. I've already been asked about whether SpiderMonkey could be made to work in that context. M

Re: [dev-servo] meeting notes (COW DOM)

On Tue, Jul 8, 2014 at 2:55 PM, Cameron Zwarich wrote: > There is this blog post: > > https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/ > > I’m friends with the author and have anecdotal confirmation that the > improvements also occur on real web pages. > Good. I saw that, but w

Re: [dev-servo] meeting notes (UTF8)

On Tue, Jul 8, 2014 at 2:51 PM, Cameron Zwarich wrote: > Are UTF8-backed (as opposed to Latin1-backed) JS strings with random > access going to be a real possibility in SpiderMonkey? It’s obviously > possible to make random access work with an appropriate indexing data > structure, but popular JS

Re: [dev-servo] meeting notes (COW DOM)

On Tue, Jul 8, 2014 at 2:56 PM, Patrick Walton wrote: > Yeah, I shouldn't have mentioned safety there, since the fundamental > problem is the same whether or not you use CC or GC. You still have to > teach the JS engine or the CC about the object graph. > > We use compiler support for this in Rus

Re: [dev-servo] meeting notes (UTF8)

On Mon, Jul 7, 2014 at 7:51 PM, Cameron Zwarich wrote: > Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access > going to be a real possibility in SpiderMonkey? It’s obviously possible to > make random access work with an appropriate indexing data structure, but > popular

Re: [dev-servo] Meeting notes (Q3)

On Tue, Jul 8, 2014 at 2:48 PM, Cameron Zwarich wrote: > We would also want to ensure that Harfbuzz and Moz2D aren’t somehow > creating duplicate copies of font data on all platforms. > They don't on Gecko, we've worked on that. I agree that image data and tile buffers are going to be very imp

Re: [dev-servo] meeting notes (COW DOM)

On 7/7/14 7:11 PM, Robert O'Callahan wrote: Difficult, definitely. Performance problem ... now that we have incremental CC and bunch of other optimizations, I feel like it isn't. At least compared to any other viable GC approach, all of which have their own performance pitfalls. Safety problem ..

Re: [dev-servo] meeting notes (COW DOM)

On Jul 7, 2014, at 7:11 PM, Robert O'Callahan wrote: > zwarich: JITting will give a huge benefit. > > Are there experimental results showing this? Because I haven't seen any > yet, and I'd like to :-). There is this blog post: https://www.webkit.org/blog/3271/webkit-css-selector-jit-compiler/

Re: [dev-servo] Meeting notes (Q3)

Sorry, I only just got to the workweek graphics meeting notes :-). Servo will need to support 2D canvas, and it requires something like Moz2D. So I think you're stuck with it or something like it. I'll talk to Bas etc about fixing some of the resource management issues your notes allude to in Moz

Re: [dev-servo] meeting notes (UTF8)

Are UTF8-backed (as opposed to Latin1-backed) JS strings with random access going to be a real possibility in SpiderMonkey? It’s obviously possible to make random access work with an appropriate indexing data structure, but popular JS benchmarks are pretty sensitive to string performance. Camer

Re: [dev-servo] Meeting notes (Q3)

On Jul 7, 2014, at 6:39 PM, Robert O'Callahan wrote: >> jack: We also had questions about replacing Azure with a thinner layer for >> disk/memory reasons. We talked to Bas about our options. He has some ideas >> already about what he wants to build as a new browser-focused graphics API >> from sc

Re: [dev-servo] meeting notes (UTF8)

On 7/7/14, 10:01 PM, Robert O'Callahan wrote: One thing not mentioned in the notes is that Spidermonkey is adding Latin-1 string support, so hopefully it will be pretty easy to avoid converting ASCII-only strings at WebIDL boundaries. Note that they also are adding GC-unstable string chars, so

[dev-servo] meeting notes (COW DOM)

> > >- pcwalton: if we can offer things like getComputedStyleAsync, that >could be a bigger win for authors using them. >- jack: that doesn't help us now. > > Apart from what jack said, getComputedStyleAsync might be unusable for a lot of Web authors. Personally I agree with the conclu

[dev-servo] meeting notes (UTF8)

I'm excited about pushing UTF8 as far as possible! One thing not mentioned in the notes is that Spidermonkey is adding Latin-1 string support, so hopefully it will be pretty easy to avoid converting ASCII-only strings at WebIDL boundaries. It would certainly be ideal if Spidermonkey eventually sup

Re: [dev-servo] Meeting notes (Q3)

> I wonder why Moz2D memory usage is a problem for Servo when we're shipping > Gecko (with Moz2D) on a 128MB phone. Not to distract from your valid points, but some of the context for this was about a much lower memory device. It's not clear it's even possible, but the question was whether we coul

[dev-servo] meeting notes (incremental layout)

> > >- jack: can we avoid width recalc when changing vertical height? >pcwalton: that will break with vertical writing modes, among other >things. not sure it's a good optimization. > > I'm not sure what jack had in mind exactly, but one very important incremental layout case is appendi

[dev-servo] Meeting notes (Q3)

> > jack: We also had questions about replacing Azure with a thinner layer for > disk/memory reasons. We talked to Bas about our options. He has some ideas > already about what he wants to build as a new browser-focused graphics API > from scratch. But that would be a multi-year, multi-person proje

[dev-servo] Meeting notes rollup: 6/9, 6/17, 6/23, 6/30, 7/7, and 6/1 workweek sessions

Sorry about this; I didn't realize how far behind we were on posting meeting minutes. https://github.com/mozilla/servo/wiki/Meeting-2014-06-09 - (prebuilt Rust status; next Servo workweek; Servo logo) https://github.com/mozilla/servo/wiki/Meeting-2014-06-17 (Weekly statuses; approval workflow

Re: [dev-servo] Cargo in Servo (Re: 2014-06-30 meeting)

On 07/07/14 17:12, Steve Klabnik wrote: ... and like magic, they have just appeared! https://github.com/rust-lang/cargo#installing-cargo What a coincidence! Thanks Steve :) -- Simon Sapin ___ dev-servo mailing list dev-servo@lists.mozilla.org https:/

Re: [dev-servo] Cargo in Servo (Re: 2014-06-30 meeting)

... and like magic, they have just appeared! https://github.com/rust-lang/cargo#installing-cargo ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] Cargo in Servo (Re: 2014-06-30 meeting)

Cargo also uses bors, so there should be a nightly snapshot of it available publicly soon as well. Don't know if that would help. ___ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo

Re: [dev-servo] rust-http, Teepee, and Fetch

I don't know that thinking about a fetch crate in terms of a submodule is particularly useful. I guess the idea is that it would be easy for other Rust programmers who want to make HTTP requests, but that sounds like a better fit for an API that is part of an HTTP crate, rather than trying to a

Re: [dev-servo] rust-http, Teepee, and Fetch

On 7/7/14 6:17 AM, Manish Goregaokar wrote: Teepee is the replacement for rust-http but it's progressing rather slowly right now. It's also "over-engineered" (as Simon puts it), but it seems to fix most of rust-http's problems. I guess we'll eventually be switching over to Teepee. That's not a

[dev-servo] rust-http, Teepee, and Fetch

*I was going to bring this up in today's meeting, but I'm not sure if I can turn up due to Internet issues.* So I've been working on CORS on the past week, and it's more and more evident that it would be best if most of the Fetch spec (except the webidls at the bott