Meeting 2013 06 24

Servo Meeting 2013-06-24

Agenda

• oscon
• cmr's interning trait
• rust 0.7 port

Attending

jack, dherman, azita, eatkinson, simonsapin, eschweic, jdm, tikue, brson, cmr, pcwalton

oscon

• azita, dherman: (talking about poster plans)
• azita: graydon, brson, pcwalton, dherman will be attending

string interning

• jack: cmr proposed an interner trait
• dherman: tying ourselves to spidermonkey is tying ourselves to a moving train
• pcwalton: spidermonkey won't update c bindings for us
• dherman: does swig do this?
• pcwalton: it may not be that much work for us to maintain C bindings
• pcwalton: what i remember is that we don't necessarily need threadsafe creaton, but the consensus was that we need a string hierarchy probably with an enum that handles owned strings and interned strings so that APIs can be polymorphic over both
• brson: teh ahrd part is the implementation. the interface is not all that interesting, and there is a lot of work to do before we can commit to an interface.

rust 0.7

• brson: last week I got through a linux build, but can't run it on linux at the moment. today's i'll start doing macos stuff.
• jack: jdm tracked down that linux bug to an intel driver problem and i'm working on a fix
• brson: i'm updating the scheduler to b eable to run real code. it can run rustc now.

skia gl

(some discussion of refactoring specifically around AzSkiaMakeCurrent)

css

• simon: i have been porting old code and catching up with spec changes in css spec. shouldn't take much longer. i'm still looking into gecko's optimizations and selector matching.

• dherman: in french, servo is brain :)

rendering

• pcwalton: cpu rendering is working except that's it's vertically flipped. the gl context setting is really ugly so i want to fix that the right way.

• jack: more research needed about gpu scheduling,

• dherman: we can talk to hardware vendors about support

• pcwalton: there is a context priority extension in opengl

• jdm: after discussions with david bruant i got intersted in iframes in servo and wanted to know if anyone has objections to working on iframes.

• pcwalton: tikue has been working on this. you guys should talk about this.

• dherman: what's the motivation?

• jdm: in paritciular for non-same-origin or sandboxed iframes the ways you can interact are so narrow that you could get benefits like worker just by having a sandboxed iframe doing stuff in parallel.

• dherman: iframes come with all the DOM goop

• pcwalton: i was talking to brian smith and jesse about doing this. chrome is doing this. they are working on putting every cross origin iframe in a separate process, but it's way too many processes if you do it naively. chrome may restrict this to only google properties or break sites taht have too many iframes. their motivation is security not parallelism. you want to enforce the same restrictions. don't want to compromise things such that your bank ends up in an iframe.

• dherman: have we given up on rust tasks as isolation boundaries?

• pcwalton: i talked to brian about this as well. every time i talked about putting gpu commands in a separate process, he claimed it's really complicated and its security theater. it may not buy the users any extra security. a lot of it is marketing.

• pcwalton: i personally want servo to be the most secure browser on the planet. the problem is spidermonkey. everything else would be ok with rust task system but not spidermonkey.

• dherman: specifically the jit?

• pcwalton: harfbuzz and freetype are also somewhat scary, but spidermonkey is a massive risk. my point of view is that we need to try to do everything that chromium does, but we can hopefully do it smarter.

• pcwalton: when it comes to things like putting iframes in a separate process, it's hard. we've been talking a lot aobut how to let remove iframes execute in parallel.

• dherman: there are some race conditions related to specific aspects of the global context. maybe there's nothing when its' XO.

• pcwalton: there's a practical benefit to this. it would make all the like buttons run off thread, and that is actually a big deal.

• dherman: we're the only ones out there finding out how to parallelize the web, and part of our role is to propose new apis that we would like. if they are easy to parallelize, then existing engines will parallelize them too

• pcwalton: want ot have getClientRect be async

• dherman: if we can show real world examples with these proposals then it will make a stronger case.

• pcwalton: need to solve a few other issues before we have good performance on ajax-y, app-y stuff. ocne we're only rendering the visible reason i'll be very curious to see what perofrmance things remain.

• pcwalton: what's the status of floats?

• eatkinson: i've done most of the hacking to get them into the pipeline, working on the specific algorithms.

• pcwalton: can they be landed as is or will they break everything right now?

• eatkinson: on pages that have floats it will probably break them. it would probably crash wikipedia.