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 Moz2D. I think there are some things we can easily
improve there.


>    - martin: Now for fixed pos elements, it looks like overflow is
>    calculated as if the display port is at 0,0. Does that seem correct?
>    - pcwalton: For fixed position elements, they get a separate layer, so
>    you can use 0,0 and it should be fine... maybe check via mail to the
>    mailing list on what to do there so we can ask roc and/or bz? I don't know
>    what the right thing to do with position:fixed is off the top of my head.
>    - pcwalton: I think you're going to always want to render all
>    position:fixed things and never cull them out. So, how do we know to
>    descend into elements that contained fixed position things. Maybe we should
>    just have a list of them on the root, since that's their containing block
>    anyway and always go into the unconditionally. You want to descend into
>    containing block that intersect with the viewport. In this case, it's the
>    root, so you'll always want to.
>
> I'm not really sure what the question is. In Gecko the overflow area for
an element, er frame, is relative to the frame's own origin. position:fixed
content doesn't move relative to the viewport but we do compute its
overflow area based on the displayport bounds; this might be overkill but
it is sometimes necessary, e.g. during async pinch-zoom-out.

We mostly avoid culling involving position:fixed content, to make async
scrolling work, but we did find one case is important: where a
position:fixed element covers the entire viewport, we cull everything
behind it.

Another issue related to this is that getting 'opacity' and other container
effects to work properly with position:fixed and other out-of-flow content
is tricky. Consider e.g.
<div style="opacity:0.5">...<div style="position:fixed">...</div>...</div>
In Gecko we identify the out-of-flow content that is visible by traversing
special child lists for the abs-pos, fixed-pos etc children of a containing
block/viewport. But we can't paint them there and then because in this
example the fixed-pos content must be rendered as part of the in-flow
opacity:0.5 div (arbitrarily far away in the frame tree). So, after
identifying the OOF content we need to draw, we set flags to ensure our
frame-tree traversal descends down to the placeholder whether or not it's
on-screen, and build display items for the OOF content in the context of
the placeholder.

I hope some of this is helpful...

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.
_______________________________________________
dev-servo mailing list
dev-servo@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-servo

Reply via email to