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