Skip to content

Meeting 2014 02 03

Jump to bottom
Lars Bergstrom edited this page Feb 4, 2014 · 3 revisions

Agenda

  • return 3 vs. return 3;
  • Handling github issues: create more E-Easy? And how should people 'claim' them and get them 'fixed/closed'?
  • Display lists to compositor layers

Attending

  • larsberg, ibnc, samsung, azita, pcwalton

trivial syntax issue

  • larsberg: if a function has type -> int, should any return have a trailing ;? So return 3 or return 3;?
  • pcwalton: I omit all semicolons, but there's no style guide
  • larsberg: Was just looking for a preference because it's a little mixed in Servo
  • pcwalton: I have no preference.

Display lists and compositor layers

  • ibnc: Multiple display lists have landed. Little confused because we have displaylists on one pipeline and they all show up in one render layer. Do I need more pipeline ids?
  • pcwalton: No, just one pipeline, but multiple layers per pipeline.

reftests

  • larsberg: still stabilizing reftests. Much better now (no more async image loading).

event handlers for DOM objects

  • sammykim: josh talked about implementing event handlers for DOM objects. two weeks ago at the workweek, jack told us he will impement it. If there's no progress, we want to take it.
  • larsberg: I do not believe he has worked on it yet. send me the issue number and I will check with jack.
  • sammykim: I will send it after this meeting is finished

tables

  • june0cho: implementing tables. We are waiting for the PR review. After reviewing, we will work on anonymous table.
  • larsberg: jack is looking at this right now and should have feedback soon. He is at a workweek right now, though.

absolute positioning

  • pradeep: stacking contexts. we want implement absolute positioning and stacking context
  • larsberg: that would be great. ibnc landed multiple display lists and rendering, but you can do absolute positioning and stacking contexts. feel free to ask if you have any questions.

list items and generated content

  • recrack: generated lists and are looking at simonsapin's suggestions
  • larsberg: if you have questions about simonsapin's suggestions, please send them to us

Question about displaylists

  • pradeep: we currently have a list of lists. instead, we could annotate each display item with the layer we want to put it into. then we don't need extra allocations. at the end, we iterate over the items in each layer
  • pcwalton: that is what gecko does
  • pradeep: then we only create a stacking context for a positioned element
  • pcwalton: that's how gecko does it, but the FrameLayerBuilder is really complicated. Roc is the only one who understands how that works, so should probably not do that. But if we can save in allocations, we should definitely do that. But we can probably use smallvec optimizations, etc.
  • pradeep: those things can be handled easily if you have them annotated; then clip and opaque would work
  • pcwalton: If you knew up-front what layer everything was going to go into, it would not be too bad. I am concerned about creating a display list and then trying to decide based on it what layer it goes into. But if you had a display list where you had layers inside the display list, and you explicitly knew waht layer you were creating. If you are just creating a tree structure with the structure inside it, it's basically the same.
  • pradeep: the z-index only defines the order in which they're painted and does not define the layers
  • pcwalton: multiple display lists may be rendered to different textures
  • pradeep: the z-index only defines the painting order for the descendents in the stacking contexts. you don't need the display lists
  • pcwalton: as long as we have methods for determining the layers from the display list and easily determine what layer it belongs tpo.
  • larsberg: need to watch out for animations - they require layers
  • pcwalton: yes! any animation will be promoted to a new layer so it can be done on the GPU. After the animation is complete
  • pradeep: for elements with separate z-index, you need to be able to handle them separately? So the display lists need multiple properties; ones with and without z-index.
  • pcwalton: not as familiar with the painting ordering rules, but I'm not an expert here; we should talk with SimonSapin as well. But it sounds OK to me.
  • pradeep: I will post my idea in the issue, and you can review it?
  • pcwalton, larsberg: yes
Clone this wiki locally