Skip to content
Jack Moffitt edited this page May 13, 2013 · 2 revisions

Servo Meeting 2013-05-13

Agenda

  • hiring
  • rust-opengles
  • c unions / jsval
  • reflow
  • releng update
  • interns

Attending

jdm, azita, jack, brson, seth

reflow

  • jdm: issue 415. need to trigger reflow immediately so that we can block on it if we need to query it.
  • ...
  • jdm: boris and roc are concerned that we get this at least as good as gecko.
  • brson: how are we now?
  • jdm: no idea because of these kinds of problems
  • brson: this change looks good me

c unions / jsval

  • jdm: what exactly is the issue here?
  • brson: jsval is a union. in rust we make it a scalar with the same size, but c calling conventions are different between structs and scalars, and when calling native code, we use the wrong calling convention. rust needs to pretend it's a struct.
  • jdm: does this show up only on android.
  • brson: i believe that's the case.
  • jack: so x86 has the same calling convention for values and structs?
  • brson: yes.
  • jdm: we need to stop fixing this piecemeal and find a real solution.
  • brson: i'm not sure what the scale of the workarounds are.
  • jdm: we change jsval to uint64_t.
  • brson: we're doing the workaround backwards. on the c side, we're passing int64 to c, and on...
  • brson: for every c call we do a conversion to a union. instead, on the rust side, we should define it as a struct so all the calls are correct. we did the workaround backwards to start with.
  • jack: we can change this to a newtype struct containing a int64_t and it should use the correct calling convention correct?
  • brson: yes

rust-opengles

  • jack: lots of contributors using for making games in Rust, adding API calls that don't currently exist on all platforms, causing breakage
  • jack: how is this handled usually? dynamic probing?
  • brson: yes
  • jack: can we do that in rust?
  • brson: no
  • jack: should we just hardcode per-platform existence with attributes? can we differentiate between 10.6 and 10.8?
  • brson: we can't right now, but could with small configure pass to set rustc flags
  • brson: bjz is working on a more comprehensive opengl binding, but it's blocked on things like dynamic probing. we will probably want to move to that once it's in a good place.
  • jack: we should hold off on any big refactoring of rust-opengles until that is farther along then.
  • jack: perhaps the right thing to do is to limit to OpenGL ES only, except for critical things needed for performance. i'll talk to the contributors and see what they need these functions for.

android build pull requests

  • jack: lots of removal from submodule makefiles
  • jdm: looks like it's all added as exports in the top-level servo makefile
  • jack: that breaks building submodules in isolation. I'll talk to them about putting it back.

interns

  • jack: "performance monitoring" project is underspecified; I'm thinking of a task that receives messages to track performance characteristics and process the data.
  • brson: will need to ensure the sending can be turned off, has performance implications.
  • jack: with regards to "reducing blocking" intern project, what about string interning?
  • brson: very broad problem; for example, libcss has its own interning solution. samsung has repo open to reimplement libcss in rust and fix interning there, which is probably the best way to solve it. any solution should ideally be used everywhere to reduce copying, but this seems like a very hard problem.
  • jack: patrick most interested in tiling, so display lists aren't part of the work. gecko uses DLBI, we use dirty rect right now. Switching to display lists will have ramifications, it would be good to have someone work through those.
  • seth: I'd like to see something like a GANTT chart showing where we're blocking in the pipeline
  • jack: That's the idea. Something like Chrome's timeline would be the ideal end goal. We need something like that.
  • jack: a good starter project might be display list culling, which has a small scope. brson: we need to fix the display list structure itself. images are ARCs but perhaps should be futures?
  • jack: they really need to start as futures, end as ARCs, and have partial access in between as data is decoded and ready. the data structure and concurrency needs of this need to be explored.
  • seth: you really want streams, since video potentially never complete.
  • jack: how about the layout related projects? seth is working there, so we should pick some things that have minimal overlap.
  • seth: probably margin collapsing and floats are a good project. they are intertwined.
  • jack: and patrick's graphics intern?
  • pcwalton: I am thinking about scrolling related issues.

releng update

  • jack: ben was blocked last week on IT, but expects to have something running this week. he'll ping us when it's ready.